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AIR  WAR  COLLEGE  RESEARCH  REPORT  ABSTRACT 

/ 

TITLE;  Systems  Management  of  Air  Force  Standard 

Communications-Computers  Systems — There  Is  a  Better 
Way  / 

AUTHORS:  Robert /A.  Allen,  Jr.,  Lieutenant  Colonel,  USAF 
Joseph/ William  (Bill)  Davis,  GM-14,  USAF 
Gary  M.  Musgrove,  Lieutenant  Colonel,  USAF 

~Ar TilaeuooloB-^of-  USAF  policy  and  management  proce¬ 
dures  for  acquiring  and  fielding  standard  communications 
computer  systems.  A  review  of  current  Air  Force  base-level 
conditions  Is  made  to  assess  the  Impact  of  functionals 
acquiring  and  fielding  unique  computer  systems  through  the 
stcmdard  systems  contracts  and  current  acquisition  process. 
An  analysis  of  the  Air  Force  acquisition  and  Life-Cycle 
Management  process  Is  made  to  assess  the  viability  of 
existing  AF  Regulations  700  and  800  toward  achieving  maximum 
efficiencies  from  Life-Cycle  practices.  A  further  exami¬ 
nation  of  the  Air  Force  organizational  structure  Is  made  to 
determine  deficiencies  and  to  make  recommendations.  The 
lack  of  architecture,  central  authority,  and  adherence  to 
existing  Life-Cycle  Management  policy  causes  a  fragmented 
approach  to  acquiring,  controlling.  Integrating,  and 
providing  Life-Cycle  Management  for  communlcatlons-computer 
systems  In  the  Air  Force.  Conclusions  are  drawn  to  assist 
In  overcoming  these  deficiencies.  /  i  f  J  1 _ _ 
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CHAPTER  I 


INTRODUCTION 

The  United  States  and  the  free  world  are  totally 
dependent  upon  computers  and  computer  technology.  The 
efficiencies  and  effectiveness  of  computers  permeates  all 
functions  of  our  lives  from  environmental  control  to  Inter¬ 
national  banking  and  defense.  Growth  of  space  age  tech¬ 
nology  Is  driven  by  the  accelerating  need  and  competition 
within  government  and  the  private  business  community  for 
business  and  scientific  use. 

The  miniaturization  of  electronic  components  and 
development  of  super  conductive  materials  for  high  speed 
transfer  of  simple  logic  data  allows  for  low  cost  multi 
purpose  systems  to  move,  store,  and  retrieve  Information  In 
a  variety  of  ways.  The  effectiveness  of  these  systems 
depends  upon  their  design  and  Intended  use  In  relation  to 
other  such  systems. 

The  good  news  Is  we  have  successfully  Integrated  the 
technological  upheaval  Into  the  defense  force  to  achieve 
successes  heretofore  unheard  of  In  national  defense  systems. 
The  bad  news  Is  technology  Is  accelerating  so  rapidly  that 
hax*dware  and  software  are  now  driving  the  requirements 
development  process.  Care  must  be  taken  to  ensure  that 
systems  being  fielded  conform  to  an  archectlture  that  Is 
supportable,  expandable,  and  capable  of  contributing  to  and 
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enhancing  our  warfighting  capability.  This  paper  Is  a 
thesis  focused  on  the  problem  of  acquiring  and  fielding 
standard  communlcatlons-computer  systems  to  meet  Air  Force 
needs  In  the  face  of  rapidly  changing  technology  and 
decreasing  defense  expenditures.  The  authors  reviewed  the 
problem  and  support  the  thesis  that  a  lack  of  archeclture 
and  Life-Cycle  provisioning  prohibits  effective  management 
of  these  resources,  thereby  distorting  their  use  at  base 
level. 
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CHAPTER  II 


THE  PROBLEM 

Air  Force  functional  managers  are  acquiring  and 
fielding  communications  computer  systems  unique  to  their 
functional  area  without  regard  to  fully  implementing  DOD  and 
Air  Force  Life  Cycle  Management  (LCM)  practices.  Conse¬ 
quently,  Management  is  unable  to  account,  control,  or 
provide  LCM  visibility  for  the  communlcatlons-computer 
systems  purchased.  Additionally,  organizations  are  not 
designed  or  equipped  for  efficient  LCM  requirement. 

Without  a  carefully  developed  LCM  philosophy  the 
systems  management  function  becomes  indecisive  and  useless 
to  management.  Life  support  options  for  economic  system 
efficiencies  are  lost  and  direct  mission  degradation 
results.  The  increasing  demands  for  integrating  standard 
small  computers  into  basewide  networks  to  share  and  distri¬ 
bute  common  data  compounds  the  problem  as  configuration 
management  of  hardware  and  applications  software  become 
critical  to  the  base  distribution  systems  visibility  and 
efficiency. 

The  Concern 

The  authors  research  initially  focused  on  attempting 
to  examine  the  Impact  from  acquiring  large  numbers  of  small 
and  standard  computers  without  sufficient  guidance  and 
structure  in  the  field,  and  to  ensure  those  systems  receive 
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proper  Life  Cycle  Management  and  line  Item  management.  Our 
thesis  Is:  An  Impossible  managerial  situation  exists  today 
whereby  the  proliferation  of  small  and  standard  computer 
systems  exceeds  the  Air  Force’s  ability  to  ensure  the  equip¬ 
ment  purchased  Is  on  board,  meets  the  customer  needs,  and  Is 
receiving  proper  management  visibility  for  Life  Cycle  needs. 
Acquisition  of  standard  computer  systems  through  the  General 
Services  Agency  (GSA)  contracts  gives  the  user  the  ability 
to  spend  local  operations  and  maintenance  monies  to  purchase 
lines  of  small  computer  software  and  hardware  from  the  GSA 
catalog  through  base  supply  at  very  economical  costs.  The 
use  of  standard  system  purchasing  contracts  also  allowed 
functional  acquisition  of  unique  systems  to  support  adminis¬ 
trative  and  business  functions  throughout  the  Air  Force. 

The  Reagan  Administration’s  large  Influx  of  money  Into 
defense  In  the  early  1980s  provided  the  Impetus  for  spending 
at  both  ends  of  the  spectrum  on  new  technolgles  for  tele¬ 
communications  and  Information  processing.  The  pent-up 
demand  for  new  systems  was  unleashed  and  a  myriad  of 
contracts  were  made.  Today,  the  Air  Force  has  fielded  over 
190,000  small  and  standard  computers  In  the  name  of  economy 
of  force  and  greater  efficiencies  through  manpower 
reductions.  Systems  were  purchased  and  fielded  without  full 
assessment  of  the  base  cable  distribution  system  needs  or 
long-term  maintenance  needs.  Standalone  mainframes  (mini 
computers)  were  purchased  outside  the  formal  budgeting 


4 


process  established  In  APR  800  and  700  series  to  expedite 
procurement  and  delivery  using  commercial  off-the-shelf 
hardware  with  custom-developed  applications  software.  The 
uniqueness  of  these  functional  applications  restricts  the 
utility  of  the  systems  once  Installed,  Some  examples  of 
stemdard  functional  systems  fielded  are  as  follows; 

EXAMPLES  OF  AIR  FORCE  STANDARD  SYSTEMS 

Functional 


Reprographics  Automated  Manaagement  System  (RAMS)  SAF/AAD 

Records  Information  Management  System  (RIMS)  SAF/AAD 

Publication  Distribution  Office  System  (PDOS)  SAF/AAD 

Comptroller  Office  of  the  Future  (COOF)  SAF/AC 

Life  Cycle  Military  Pay  System  (LCMPS)  SAF/AC 

Base  Level  Accounting  and  Reportinc  System  (BLARS)  SAF/AC 

Retired  Annuitant  Pay  System  (RAPS;  SAF/AC 

Standard  Materiel  Accounting  System  (SMAS)  SAF/AC 

Air  Force  Standard  Civilian  Automated  Pay  System  (AFSCAPS)  SAF/AC 
Central  Civilian  Pay  System  (CCPS)  SAF/AC 

Command  Budget  Automated  System  (CBAS)  SAF/AC 

Automated  Travel  System  (ATS)  SAF/AC 

Joint  Uniform  Military  Pay  System  (JUMPS)  SAF/AC 

Departmental  Accounts  Receivable  System  (DARS)  SAF/AC 

Air  Reserve  Forces  Pay  and  Allowance  System  (ARFPAS)  SAF/AC 

Accountability  and  Fund  Reporting  System  SAF/AC 

Defense  Integrated  Financial  System  -  FMS  Support  SAF/AC 

Base  Contracting  Automated  System  (BCAS)  SAF/AQ 

Standard  Base  Supply  System  (SBSS)  AF/LE 

Combat  Ammunition  System  (CAS)  AF/LE 

Core  Automated  Maintenance  System  (CAMs)  AF/LE 

Contingency  Operation/Mobility  Planning  and  Execution 

System/Logistics  Module-Base  (COMPES/LOGMOD-M)  AF/LE 

COMPES/Logi sties  Module-Major  Command  (COMPES/LOGMOD-M) 

Logistics  Force  Packaging  (LOGFOR)  AF/LE 

COMPES/Logi sties  Module-Logistic  Feasibility  Analysis 

Capability  (COMPES/LOGFAC)  AF/LE 

COMPES/Logi sties  Module  Logistic  Planning  (C0MPES/L06PLAN)  AF/LE 
Combat  Fuels  Management  System  (CFMS)  AF/LE 

Cargo  Movement  Operations  System  (CMOS)  AF/LE 

Fuels  Automated  Management  System  (FAMS)  AF/LE 

On-Line  Vehicle  Interactive  Management  System  (OLVIMS)  AF/LE 

Air  Force  Equipment  Management  System  (AFEMS)  AF/LE 

Work  Information  Management  System  (VIMS)  AF/LE 

PMEL  Automated  Management  Subsystem  (PAM^  AF/LE 

Red  Horse  Infonmatlon  Management  System  (RHIMS)  AF/LE 
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Services  Information  Management  System  (SIMS) 

MIMS  -  Expansion  (MIMS>E) 

Site  Automation  System  (SAS) 

Integrated  Graphics  System  (IGS) 

Computer  Aided  Load  Manifesting  System  (CALM) 

Combat  Supply  System  (CSS) 

MAJCOM  On-Line  Aerospace  Vehicle  Trainer  Reporting  System 
(MOATRS) 

Combat  Logistics  System  (CLS) 

Comprehensive  Engine  Management  System  (CEMS) 

Aerospace  Vehicle  and  Equipment  Inventory »  Status 
and  Utilization  Reporting  System  (AVISURS) 

Combat  Supplies  Management  System  (CSMS) 

Micro-Computer  System  for  POM  Development  (MICROPOM) 

Base  Manpower  Data  System  (BMDS) 

Command  Manpower  Data  System  (CMDS) 

Security  Police  Automated  System  (SPAS) 

Aerospace  Safety  Automation  Program  (ASAP) 

Automated  Hazard  Abatement  Program  System  (ahaps) 

Sentinel  Byte  (Intelligence  System)  (PROTOTYPE) 
Intelligence  Data  Handling  System  (IDHS) 

Tactical  Information  Processing  and  Interpretation, 
Display  and  Control /Storage  and  Retrieval  Segment 
(TIPI  DS/SR) 

TAC  Information  Processing  and  Interpretation  System, 
Image  Interpretation  Segment  (TIPI  II) 

Advanced  Personnel  Data  System  II  (APDS  II > 

Personnel  Concept  III  (PC  III) 

Combat  Personnel  Control  System  (CPCS) 

Personnel  Data  System- 90  (PDS-90} 

Base  Level  Personnel  System  (BLPS) 

COMPES/Manpower  and  Personnel -Base  (COMPES/MANPER-B 
COMPES/Manpower  and  Personnel -MAJCOM  (COMPES/MANPER-M) 
Pipeline  Management  System  (PMS  and  PMS-II) 

Medical  Readiness  Assemblage  Materiel  System/Medical 
Materiel  Management  System  -  On-Line  (MEDRAMS/MMMS-OL) 
Computerized  Occupational  Health  Program  (COHP) 

Coronary  Artery  Risk  Evaluation  (CARE)  Program 
Automated  Commissary  Operations  System  (ACOS) 

Air  Force  Claims  Information  System  (AFCIMS) 

Air  Force  Justice  Information  System  (AFJIMS) 

Federal  Legal  Information  Through  Electronics  (FLITE) 
Judge  Advocate  General  Data  Automation  Program  (JAGDAP) 
Chaplains  Automated  Pastoral  Support  System  (CAPSS) 
Standard  Base  Level  Computer  (SBLC) 

Transportable  Shelter  System 
Remote  Job  Entry  Terminal  System  (RJETS) 
Communicatlons-Electronics  Status  and  Reporting  System 
(COMM/ELECT) 

Air  Force  Capability  Assessment  Program  (AFCAP) 

Air  Force  Operations  Resource  Management  System  (AFORMS) 
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AF/LE 

AF/LE 

AF/LE 

AF/LE 

AF/LE 

AF/LE 

AF/LE 

AF/LE 

AF/LE 

AF/LE 

AF/LE 

AF/PR 

AF/PR 

AF/PR 

AF/IG 

AF/IG 

AG/IG 

AF/IN 

AF/IN 


AF/IN 

AF/IN 

AF/DP 

AD/DP 

AF/DP 

AF/DP 

AF/DP 

AF/DP 

AF/DP 

AF/DP 

AF/SG 
AF/SG 
AF/SG 
HQ  AFCOMS 
AF/JA 
AF/JA 
AF/JA 
AF/JA 
AF/HC 
AF/SC 
AF/SC 
AF/SC 

AF/SC 

AF/XO 

AF/XO 


Uartlne  Aircraft  Activity  Reporting  System  (KAARS) 
COMPES/Operatlon  Planning  Module  (COMPES/OPSMOD) 
Worldwide  Military  Comnand  and  Control  System  (WWMCCS) 
Air  Force  Comnand  and  Control  System  (AFC2S} 

Critical  Intelligence  Comnunicatlon  (CRITICOM)  System 
Multi comnand  Comnand  and  Control  System 
Air  Traffic  Control  System 

Base  Information  Data  Distribution  System  (BIDDS) 


AF/XO 

AF/XO 

AF/XO 

AF/XO/SC 

AF/IN 


CHAPTER  III 


TECHNOLOGICAL  CHANGE 

The  difference  In  technology  and  applications  Infor¬ 
mation  processing  Is  lost  In  trying  to  separate  communi¬ 
cations  processing  and  Information  flow.  Computers 
transcend  the  traditional  hardware  limitations  which  defined 
where  Information  processing  started  and  ended.  New  methods 
of  defining,  categorizing  and  acquiring  systems  are 
required.  The  old  telecommunications  days  are  gone  where 
the  change  cycle  was  slower  and  we  had  time  to  plan. 

Planners  could  phase  their  programs  with  the  technological 
advances  Improving  product  line  as  new  capabilities  were 
Introduced.  Today,  and  more  so  In  the  future,  earlier 
commitments  are  required  to  keep  pace  with  change.  The 
computer  Industry  Is  expcmdlng  product  options  so  fast  only 
the  most  enlightened,  dedicated,  and  flexible  organizations 
are  equipped  to  take  advantage  of  the  offering.  And  then, 
one  must  be  continually  alert  to  new  Industry  developments 
to  prevent  loss  of  Investment  through  Improvements  to 
existing  capabilities.  The  Air  Force  computer  acquisition 
community  Is  not  organized  to  keep  pace  with  rapid  techno¬ 
logical  changes.  The  experts  say  the  Industry  Is  maturing, 
others  say  It  has  reached  a  plateau  In  preparation  for 
greater  accelerated  growth.  Here  Is  the  executives  of 
Industry  outlook: 


8 


Executive  Outlook 


John  P.  Akers,  IBM's  Chairman  and  Chief  Executive: 

We  continue  to  Invest  for  the  long  term,  and  we  remain 
confident  about  the  future  of  our  Industry  and  IBM. 

Frederick  Wlthlngton,  Independent  analyst  based  In 

New  York: 

There  Is  a  real  possibility  that  the  Industry  Is 
maturing.  .  .  In  the  highly  developed  markets — Western 
Europe,  the  US,  and  Japan — all  the  basic  computer 
services  are  already  being  provided. 

He  also  said 

The  moat  likely  growth  areas  are  Image  processing,  arti¬ 
ficial  Intelligence  and  Instructional  and  home 
computing. 

These  markets  have  not  tended  to  open  up  easily.  So  we 
are  at  a  watershed.  Either  we're  going  to  saturate  or 
we're  going  to  leap  ahead  Into  entirely  new  territory  1 
IBM  la  becoming  more  profitable,  but  by  effectively 
cutting  back  on  what  la  .Invested  In  growth.  That  tends 
to  support  the  thesis  that  the  Industry  Is  maturing. 

Edward  Sklko,  Vice  President  for  Corporate 

Information  systems,  of  General  Electric  Company,  one  of  the 

world's  largest  computer  users  said, 

I  don't  think  personally  that  the  computer  Industry  Is 
maturing  If  maturing  means  topping  out  or  slowing  down. 
It  seems  to  me  that  In  everything  from  the  row  hardware 
technology  all  through  the  advances  In  systems  and 
application  software,  you're  continuing  to  see  sub¬ 
stantial  acceleration  of  the  technology.  There  will  be 
much  more  extensive  use  of  technology  for  things  such  as 
automated  design  and  providing  superior  customer  service 
.  .  .  Communications  within  organizations  and  between 
vendors  and  buyers  can  be  greatly  facilitated.  It  does 
not  seem  to  me  that  the  overall  opportunity  to  grow 
revenue  within  the  Industry  Is  terribly  limited.  I 
think  It's  excellent. 
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George  Christie,  Chief  Economist  of  McGraw-Hill 

Information  Systems  Co.,  said. 

Is  it  possible  the  Industry  is  maturing?  It's  not 
possible;  it's  a  fact.  Maturity  is  exactly  the  word  for 
it.  It  used  to  grow  15  percent  a  year,  steadily,  from 
the  late  1960s  to  the  early  I980.  Now  we're  in  a  ^ 
secondary  growth  stage  of  5  to  at  least  10  percent. 

Industrial  Outlook 

The  industrial  outlook  is  for  more  growth  and  inno¬ 
vative  approaches  to  developing  products  that  service  tele¬ 
communications  and  information  processing  requirements. 

Since  the  base  telecommunications  network  is  the  basis  for 
the  Air  Force  mission,  technical  leadership  and  organi¬ 
zational  discipline  are  needed  to  define  requirements,  be 
innovative  in  relation  to  the  future,  and  have  the  vision 
and  determination  to  act  decisively  in  the  face  of  change. 
Technical  competence  and  the  right  pro-active  organizational 
structure  must  be  aimed  at  innovative  approaches  in 
visualizing  operational  requirements  and  satisfying  them 
using  future  technologies  in  the  near-term.  Long-range 
planning  initiatives  are  needed  now  to  assess  and  set  into 
motion  those  Life  Cycle  actions  to  program  the  operations, 
malntentmce  and  replacement  options  that  will  modernize  the 
systems  through  incorporation  of  change  at  optimum  times. 
These  systems  provide  the  dally  operational  support  needed 
to  provide  the  administrative  and  business  functions  of  all 
US  bases  worldwide.  They  operate  the  supply  accounts, 
manage  aircraft  maintenance  and  operations,  provide  the  data 
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base  and  support  for  finance,  personnel,  contracting,  civil 
engineering,  transportation,  security  police,  base  adminis¬ 
tration,  mobility  processing,  hospital  administration  and 
mess2ige  distribution  functions.  A  breakdown  In  any  one 
system  becomes  critical  over  short  periods  of  time  to  the 
base  mission.  The  lack  of  systems  Integration  now  effects 
the  total  base  management  efficiency.  Although  they  may  not 
be  physically  Integrated,  a  data  update  or  modernization 
enacted  In  one  system  must  be  developed,  tested  and  released 
In  total  cognizance  of  Its  effect  to  the  total  base  support 
functions.  The  next  chapter  focuses  on  the  acquisition  and 
Life  Cycle  Management  of  the  standard  systems  that  provide 
data  processing  support  at  the  base  level. 
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CHAPTER  III  (Pages  8-11) 

1.  Peter  Coy,  Associated  Press  Writer, 
Divided  Over  Whether  Computer  Industry  Maturing, 
gomery  Advertiser,  2k  January  1988,  p.  5B. 
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CHAPTER  IV 


THE  BASE-LEVEL  ENVIRONMENT 
The  standard  data  systems  supporting  the  base  are 
the  product  of  evolution.  The  concept  of  centralized  data 
processing  developed  In  the  early  1960s  by  the  Federal 
Government j  grew  from  government's  sponsorship  of  the 
computer  Industry  and  ''large  box"  technology.  Today,  the 
concept  remains  the  same  but  technology  affords  greater 
efficiencies  through  small  box  microprocessors  performing 
tuilque  fimctlons  throughout  the  base.  The  core  of  the  base 
standard  systems  remains  the  Phase  IV  SHOO  malnfraime 
computer.  Software  Is  centrally  developed,  tested  and 
released  by  the  Standard  Systems  Center  (SSC),  Gunter  APS, 
by  the  Standard  Systems  Manager  (SSM).  The  Phase  IV  system 
Is  operated  centrally  by  an  APCC  squadron  to  provide 
computer  support  to  base  level  functional  users  who  access 
the  system  through  on-line  computer  terminals  or  micro¬ 
processors  connected  through  the  base  central  switching  and 
cable  distribution  network.  Numerous  time-shared  users  are 
also  remoted  from  on  and  off-base  under  a  distributive 
architectural  concept  of  maximized  system  availability  to 
any  DOD  requested  user.  Eighty-seven  Air  National  Guard  and 
11  Air  Force  Reserve  units  are  serviced  from  our  active  duty 
bases  } 


13 


The  Increasing  demand  on  the  Phase  IV  system. 


saturation  of  base  telecommunications  switching  networks, 
and  need  for  decentralization  of  computer  processing 
throughout  the  functional  areas  causes  the  Air  Force 
functionals  to  seek  their  own  capability  using  deployable 
and  fixed  microprocessors  to  perform  their  unique  processing 
requirements.  These  systems  remain  Independent  data  sources 
for  transfer  of  functional  data  up  to  the  MAJCOM  and  HQ  USAP 
levels.  Little  has  been  done  to  Integrate  the  data  that 
transcends  functional  lines.  The  data  is  captured  in  "stove 
pipe"  functional  channels,  requiring  senior  decision-makers 
to  sift  through  duplicate  information  to  perform  additional 
analysis  before  presentation  for  decision  making. 

Our  most  critical  issues  are  accepting  the  multitude 
of  functional  systems  and  embedding  them  into  the  base 
information  processing  and  distribution  system,  then  inte¬ 
grating  the  systems  so  they  Interrelate  and  work  together  at 
base  and  MAJCOM  levels. 

The  evolvement  of  "stove  pipe"  systems  presents  a 

great  challenge  to  the  local  communications*  squadron 

commander.  The  systems  were  Independently  acquired  from 

separate  manufacturers  without  regard  for  future  Integration 

requirements  and  limitations  on  base  cable  distribution 

systems.  An  example  of  the  integration  problem  is  provided: 

The  Air  Force  has  subdivided  the  base  level  logistics 
functions  into  maintenance,  supply,  transportation  and 
procurement  organizations.  Each  of  these  areas  acts  as 
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a  separate  entity  solely  reponslble  for  its  own 
logistics  tasks.  The  related  data  systems  have  evolved 
Independently  to  support  each  of  these  areas.  No  signi¬ 
ficant  Integration  of  these  Isolated  data  systems  has 
occurred  Just  like  It  hasn't  In  the  organizations  they 
serve.  The  data  systems  strive  for  maximum  efficiency 
within  the  specialized  area  without  significant  regard 
for  the  overall  logistics  system.  Yet  these  systems  are 
Independent.  For  example,  supply  depends  on  maintenance 
for  repairing  reusable  spares  and  maintenance  depends  on 
supply  for  components  required  for  repairs.  Supply 
gives  a  requisition  to  procurement  which  Issues  a 
request  for  quotation.  Invitation  to  bid,  and  a  purchase 
order.  Even  though  supply  and  procurement  use  the  same 
computer,  data  Is  not  shared.  If  supply  and  procurement 
shared  common  data  and  had  on-line  access  to  this  data, 
manual  processes  would  be  eliminated,  duplicate  data 
entry  would  be  reduced,  and  timeliness  of  service  would 
be  Improved.  The  same  opportunities  exist  In  the 
sharing  of  data  between  supply  and  maintenance, 
logistics  plans,  supply  and  personnel,  finance  and  Just 
about  every  other  major  data  system .2 

This  Is  one  example  of  the  many  problems  Involving 
business  and  administrative  functions  computers  now  support. 
Although  these  systems  were  fielded  under  a  "standardized" 
concept,  the  differences  in  manufacutre  design,  warranties, 
contractual  obligations,  and  software  developments  to  meet 
specific  functional  area  requirements  Inhibits  Integration 
of  the  systems  and  dramatically  reduces  their  potential  use. 
The  problem  Is  severely  compounded  when  the  systems  are 
Independently  fielded  without  engineering  upgrades  or 
provision  for  Information  distribution  systems  and  other 
critical  Life  Cycle  Management  elements.  The  majority  of  our 
bases  have  completed  the  Phase  IV  Installations  and  are  In 
the  final  stages  of  engineering.  Installation  and  cutover  of 
the  Scope  Exchange  and  Scope  Dial  systems  to  replace  our 
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analog  switches  and  outmoded  cable  plants  with  electronic 
digital  switches  and  upgraded  distribution  systems.  The 
additional  Infusion  of  multiple  "stove  pipe"  systems  with 
their  required  distributive  networks  has  created  demands  on 
the  base  distribution  system  not  accounted  for  In  their 
previous  design. 

Although  technology  now  allows  us  to  multiplex  voice 
and  data  over  greater  distances  to  provide  economically 
feasible  distribution  networks  for  electronic  Integration  of 
data,  a  base  level  architecture  and  heavy  Investment  Into 
Integration  of  equipments  and  software  are  needed  before  we 
are  able  to  give  the  user  a  computer  that  operates  as 
flexible  and  friendly  as  the  telephone. 

The  crux  of  the  problem  Is  being  able  to  electroni¬ 
cally  Integrate  the  "stovepipe"  systems  under  an  archi¬ 
tectural  concept  that  allows  software  and  hardware  enhance¬ 
ment  under  a  common  management  philosophy.  To  develop  and 
Implement  such  an  Initiative  requires  centralization  of 
authority  for  problem  definition,  requirements  processing, 
engineering,  acquisition.  Implementation  and  Life  Cycle 
Management . 

The  next  chapter  reviews  the  Air  Force  Standard 
Communlcatlons-Computer  Systems  Life  Cycle  Management 
process  and  the  acquisition  procedures  to  meet  legislative 
and  DOD  directives. 
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1.  Kenneth  B.  Heltkamp,  Air  Force  Base-Level 
Information  Systems,  Air  War  College  Special  Project,  Air 
University,  Maxwell  APB,  Alabama,  April  1987,  p.  51* 

2.  Ibid.,  p. 
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CHAPTER  V 


POLICY  AND  PROCEDURES 

Combat  support  exists  to  meet  combat  operational  needs. 
Without  this  support,  combat  operations  are  Impossible. 
In  the  broadest  sense,  combat  support  Is  the  art  and  , 
science  of  creating  and  sustaining  combat  capability.^ 

Introduction. 

Previous  chapters  have  Identified  the  problem,  and 
placed  Into  perspective  the  relationship  between  standard 
communlcatlons-computer  systems,  "stove  pipe"  systems  and 
command  unique  systems.  This  chapter  focuses  on  standard 
communlcatlons-computer  system  acquisition,  and  life  cycle 
management  (LCM). 

Objectives 

The  objectives  of  this  Chapter  are  tor 

A,  Describe  the  DOD  and  DSAP  policy  concerning 
communlcatlons-computer  system  acquisition,  and  life  cycle 
meuiagement . 

B,  Compare  the  APR  700-serles  and  800-serles  regu¬ 
lation's  procedures  for  Implementing  U5AF  policy  for 
standard  communlcatlons-computer  system  acquisition,  and 
life  cycle  management. 

C,  Provide  concerns  pertaining  to  the  acquisition, 
and  life  cycle  management  of  standard  communlcatlons- 
computer  systems. 
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POP  yid  USAP  Policy  For  Communlcatlons-Computer  Systems 
Acquisition  and  Life  Cycle  MsmagemenT 

A.  POP  policy.  POP  policy  for  communlcatlons- 
computer  systems  management  Is  established  In  numerous 
directives  and  Instructions  as  Identified  In  the  Appendix. 
These  directives  and  Instructions  are.  In  most  cases.  Imple¬ 
menting  public  law.  Office  of  Management  and  Budget  (0MB) 
circular,  or  other  POP  directives  and  Instructions.  The 
Intent  of  these  directives  and  Instructions  Is  to  Insure 
appropriate  life  cycle  management,  and  address  critical 
technical,  cost  and  risk  considerations  which  allow  for  the 
effective  and  economical  system  acquisition.  In  POP 
directives  and  Instructions  communlcatlons-computer  systems 
management  Is  covered  under  the  general  topic  of  POP  Infor¬ 
mation  Resources  Management  (IRM).  For  purposes  of  this 
chapter,  communlcatlons-computer  systems  are  Included  In  the 
provisions  of  Information  technology  which  Is  a  subset  of 
IRM,  Information  technology  Is  composed  of  such  POP 
resources  as  automatic  data  processing  equipment  (APPE), 
telecommunications  equipment,  office  Information  systems  and 
other  office  automation  used  to  manipulate  or  facilitate 
Information  handling,  use,  processing,  storage,  and  manage¬ 
ment.  POP  policy  Is  clearly  Intent  on  Implementing  IRM 
aggressively  to  enhance  mission  performance  through 
effective,  economical  acquisition  and  use  of  Information. 
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The  following  DOD  policy  Issuances  relate  to  established 
coninunlcatlons-computer  systems  policy: 

1.  Management  of  Automatic  Information 
Systems 

a.  DOD  Directive  7920.1,  "Life  Cycle 
Management  of  Automated  Information  Systems  (AIS),"  October 
17,  1978,  establishes  the  process  for  administering  the  life 
cycle  of  an  AIS  with  particular  emphasis  on  the  most 
critical  early  decisions  that  Influence  AIS  cost  and 
utility.  The  policy  Is  stated  that  the  early  decisions 
shall  be  based  on  full  consideration  of  functional,  ADP,  and 
telecommimlcatlon  requirements  In  order  to  acquire  an 
effective  AIS. 

b.  DOD  Instruction  7920.2,  "Major  Auto¬ 
mated  Information  Systems  Approval  Process,"  October  20, 
1978,  sets  the  milestones  review  and  OSD  approval  decision 
process  and  procedures  for  major  AIS  meeting  high  dollar 
value  thresholds. 

2.  Information  Technology  Management 

a.  DOD  Directive  7950.1,  "Automated  Data 
Processing  Resources  Management,"  September  29 »  I98O, 
authorizes  the  publishing  of  the  ADP  Resources  Management 
Manual,  DOD7950.1M,  which  sets  forth  procedures  for 
reporting  and  Inventorying,  sharing,  and  reusing  ADP 
resources.  It  also  assigns  responsibilities  for  management 
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visibility  on  In  use  DOD  ADP  resources,  and  cost-effective 
modernization  of  ADP  support. 

b.  DOD  Instruction  7935.1*  DOD  Automated 
Data  Systems  Documentation  Standards,"  September  13*  1977* 
assigns  responsibilities,  and  authorizes  a  standard  for 
types  of  documentation,  and  requires  that  all  AIS  be  docu¬ 
mented  according  to  these  standards.  Further,  It  sets  forth 
the  procedures  for  determining  the  extent  of  documentation 
required  for  each  situation. 

3.  Information  Resources  Management  Is 
established  In  DOD  Directive  77^0.1,  "DOD  Information 
Resoiirces  Management  Program."  The  DOD  Information 
Resources  Management  (IRM)  Program  Is  designed  to  promote 
coordinated  and  Integrated  Information  management. 

To  emphasize  DOD  policy  The  Undersecretary  of 
Defense  for  Research  and  Engineering  stated  In  1983  that  DOD 
components  are  required  to  Insure  executive  oversight 
responsibility  which  Is  clearly  designated  and  are  stream¬ 
lined  as  possible;  and,  that  program  managers  are  assigned 

responsibility  and  authority  to  manage  and  be  accountable 

2 

for  program  performance. 

B.  USAP  Policy 

1.  700-Serles  regulations.  USAP  policy  per¬ 
taining  to  the  management  of  Information  systems  or  communl- 
catlons-computer  systems  acquisition,  and  life  cycle  manage¬ 
ment  Is  established  In  Air  Force  Regulation  (APR)  700-1, 


Managing  Air  Force  Communlcatlona-Computer  Systems,  15 

January  1987.  AFR  700-1  pertains  to  all  communlcatlons- 

computer  systems  regardless  of  category  and  provides  the 

foundation  for  the  700-serlea  regulations.  The  policies 

stated  In  AFR  700-1  are  that  (1)  communlcatlons-computer 

systems  will  be  developed  and  modified  only  on  the  basis  of 

documented  and  validated  minimum  essential  requirements,  . (2) 

systems  will  be  acquired  at  the  lowest  total  overall  life 

cycle  cost,  2ind  (3)  life  cycle  management  will  be 

emphasized.  Further,  AFR  700-1  establishes  management 

policy,  objectives,  and  responsibilities.  Section  A,  Life 

Cycle  Management  (LCM)  of  Communlcatlons-computer  Systems, 

emphasizes  LCM,  and  Paragraph  6  states: 

Life  cycle  management  begins  with  planning  and  continues 
through  Information  requirements  processing,  program 
management,  and  the  operational  life  of  the  system. 
System  managers,  under  a  life  cycle  management  approach, 
will  place  emphasis  on  strengthening  the  early  decisions 
which  shape  systems  reliability  and  maintainability, 
costs,  €uid  utility.  Life  cycle  management  will  also 
emphasize  management  audit  and  accountability,  logistics 
support,  life  cycle  planning  and  costing,  competition, 
preservation  and  disposition  of  Information,,  and  the 
appropriate  level  of  management  supervision.*^ 

It  Is  Important  to  point  out  that  USAF  Life  Cycle  management 

policy  applies  to  the  management  of  all  Air  Force 

communlcatlons-computer  systems.  The  life  cycle  management 

phases  are  defined  as  planning,  requirements  processing, 

program  management,  and  operational  management.  The 

planning  phase  Is  documented  In  AFR  700-2,  Information 

System  Planning.  Planning  responsibility  Is  assigned  to 


functional  and  system  managers  at  all  levels.  Planning 
activities  are  documented  In  system  planning  documents.  The 
second  phase,  requirements  processing,  flows  from  the 
planning  phase  and  begins  with  Identification  of  a  user 
shortfall.  A  review  of  the  technical  solution  to  the  short¬ 
fall  Is  performed  by  the  appropriate  communlcatlons-computer 
systems  board  (CSRD)  to  validate  and  prioritize  the  require¬ 
ment  and  approve  the  solution  If  It  has  the  authority  and 
funds  to  do  so.  APR  700-3,  Information  Systems  Require¬ 
ments  Processing,  provides  detailed  guidance  on  processing 
systems  requirements,  and  APR  700-5,  Information  System 
Requirements  Board,  further  defines  the  role  of  CSRB.  After 
a  system  has  been  approved  and  funded  the  program  management 
phase  begins.  This  phase  Is  covered  In  APR  700-4,  Infor¬ 
mation  System  Program  Management  and  Acquisition.  This 
regulation  goveims  the  acquisition,  acceptance,  and  Imple¬ 
mentation  through  commissioning.  During  this  phase  of  the 
system  life  cycle,  a  program  manager  Is  designated.  The 
program  manager  Is  responsible  to  control  systems  develop¬ 
ment  and  ensure  directives,  plans  and  guidance  are  complied 
with.  The  program  manager  Is  also  responsible  for  the 
review  and  audit  of  the  developing  program  to  ensure  the 
program  meets  the  validated  Information  requirement  at  the 
lowest  total  life  cycle  cost.  The  final  phase  of  the  life 
cycle  of  communlcatlons-computer  systems  is  the  operational 
management  phase.  During  this  phase,  functional  and  systems 
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majiagers  enpbaslze  whether  systems  remain  cost  effective  emd 
satisfy  the  original  validated  requirements.  Functional  and 
system  managers  Initiate  action  for  upgrade  or  replacement 
of  systems.  AFR  700~6j  Information  Systems  Operation 
Management,  AFR  700-7,  Information  Processing  Center  Opera¬ 
tions  Management,  and  AFR  700-8,  Telephone  Systems  Operation 
Management  provide  USAF  guidance,  policy  and  procedures 
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governing  this  phase. 

2.  800-Serles  Regulations.  While  the  700- 
serles  regulations  provide  the  basis  for  communlcatlons- 
computer  systems  acquisition  and  life  cycle  management, 
there  Is  an  Important  Interface  with  the  800-serles  regu¬ 
lations.  The  700-serles  regulations  do  not  provide  policies 
and  procedures  for  the  Identification  and  processing  of 
Statements  of  Operational  Needs  (SON),  Justification  for 
Major  New  Start  (JMSNS),  and  Joint  Service  Operational 
Requirements  (JSOR).  Communlcatlons-computer  systems 
requirements  which  must  be  processed  using  a  SON,  JMSNS,  and 
JSOR  are  processed  In  accordance  with  AFR  57-1,  Operational 
Needs,  and  the  acquisition  phase  of  those  commvinlcatlons- 
computer  systems  and  resources  acquired  using  the  AFR  800- 
serles  regulations.  For  these  requirements  the  program 
management  directive  (PMD),  will  designate  the  applicability 
of  the  700-serles  and  800-8erles  regulations.  The  HQ  USAF 
functional  staff  office  preparing  and  Issuing  the  PMD  will 
use  the  criteria  In  AFR  700-4  for  determining  the  applicable 
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series  regulation.  APR  800-2,  Acquisition  Program  Manage¬ 
ment,  16  September  I985,  with  APR's  57-1  and  55-24,  System 
Operational  Concept,  prescribe  the  system  acquisition 
procurement  appropriations,  and  the  Research,  Development, 
Test  and  Evaluation  (RDT&E)  appropriation.  Also,  Major 
systems  acquisition  programs  that  are  designed  by  the 
Secretary  of  Defense  (SECDEP)  as  an  Air  Porce  Designated 
Aacqulsltlon  Program  (APDAP)  must  be  managed  according  to 
APR  800-2.  APR  800-2  requires  the  PMD  to  Identify  the 
Implementing  command.  The  command  or  agency  so  designated 
by  Headquarters,  USAP  will  manage  the  acquisition  program. 
The  Implementing  command  appoints  a  Program  Manager  (PM)  who 
ensures  that  all  program  documents  are  prepared  and 
Issued.  The  PM  prepares  and  Issues  the  Program  Management 
Plan  (PMP)  for  managing  the  acquisition  program  In 
accordance  with  APR  800-2,  attachment  3*  Another  Important 
role  of  the  PM  Is  to  manage  the  Integrated  Logistics  Support 
Program  (ILSP),  per  APR  800-8,  until  Program  Msmagement 
Responsibility  Transfer  (PMRT).  The  ILSP  contains  the 
essence  of  the  life  cycle  management  requirements  and  the 
Implementing  command  transfers  management  of  the  program  to 
the  supporting  command.  In  accordance  with  APR  800-4, 

Program  Management  Responsibility  Transfer,  or  as  directed 
by  HQ  USAP. ^ 
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Comparison  of  APR  700-‘Serlea/800~Serle8  ^ocedures  for 
Implementing  Acquisition  and  Life  Cycle  Management 

A.  As  stated  above  the  700  and  800-serles  regu¬ 
lations  drive  the  requirements  for  acquisition  and  life 
cycle  management.  Each  has  a  specific  area  of  application 
and  Is  applied  to  the  requirements  within  Its  own  sphere. 
Generally,  the  TOO-Serles  pertains  to  commercial  off-the- 
shelf  communlcatlons-computer  systems,  and  the  800-serles 
deals  with  systems  requiring  research  and  development  effort 
and  R&D  applications.  The  TOO-serles  has  been  developed  and 
continues  to  evolve,  to  separate  from  the  normal  800-8erles 
management  (which  was  Intentionally  designed  for  R&D),  the 
less  complicated  but  critical  commercial  off-the-shelf 
procurements . 

B.  Tables  1  and  2  provide  a  comparison  of  the  plans 
required  by  the  700  and  800-8erle8  regulations  and  which 
regulations  govern  these  plans.  Study  of  the  tables  shows 
that  a  number  of  the  basic  requirements  for  program  manage¬ 
ment  and  life  cycle  management  using  either  regulation 
series  are  governed  by  many  of  the  same  policies  and 
procedures  In  both  regulations.  The  differences  on  the 
tables  are  due  to  the  evolving  nature  of  acquisition  and 
life  cycle  environment  of  communlcatlons-computer  systems, 
and  the  differences  between  standard,  command  unique,  and 
off-the-shelf  systems.  Acquisition  and  life  cycle 
management  under  one  series  does  not  mean  that  management 
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systems  under  the  other  series  are  excluded  from 
consideration  or  use.  However,  as  stated  earlier  the  800- 
series  regulations  are  primarily  used  RiD  acquisition 
programs 

C.  Because  of  the  nature  of  a  program  which  is 
acquired  under  the  800-serles,  a  very  rigid  vertical  manage¬ 
ment  structure  Is  Inherent.  The  800-serles  Implementing 
command  or  agency,  designated  by  HQ  USAP,  Is  usually  Air 
Force  System  Command  (APSC).  The  Implementing  command  (800- 
serles)  appoints  a  Program  Manager  (PM),  establishes  the 
PM's  charter,  states  the  PM’s  relationship  with  parti¬ 
cipating  commands,  and  sets  forth  the  line  authority  over 
the  PM.  The  PM  (800-series)  then  manages  the  program  by 
using  the  assistance,  advice,  and  recommendations  of  parti¬ 
cipating  commands.  The  vertical  management  structure 
extends  throughout  the  acquisition  and  life  cycle  process. 
The  program  management  plan  covers  all  aspects  of  the  life 
cycle  of  the  system  being  acquired.  It  addresses  clearly 
and  explicitly  program  objectives,  schedules,  tasks,  risks, 
participants  and  their  interrelationships,  resources 
required  and  overall  strategy.  Through  such  documents  as 
the  logistics  and  manpower  and  organization  sections  the  PM 
has  a  complete  view  of  the  program  from  a  vertical  perspec¬ 
tive,  and  probably  more  Importantly,  complete  vertical 
control  of  the  program. 
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D.  The  TOO-serles  regulations  attempt  to  Impose  the 
same  management  concepts  and  procedures  In  the  system  acqul~ 
sltlon  process  and  life  cycle  processes  as  the  800-serles. 
The  700“serles  regulations,  however,  lack  the  rigidity, 
maturity,  and  vertical  management  control  of  the  Soo-serles 
regulations.  Although  the  program  manager  Is  given  full 
responsibility  with  many  program  functions  reporting 
directly  to  him  or  her,  a  horizontal  management  structure  Is 
necessary  and  many  times  parallel  management  structures  In 
the  Implementing  activity,  the  requiring  activity.  Air  Force 
Logistics  Command,  and  the  host  command  or  commands.  While 
APR  700-M  states  that  the  Implementing  activity  appoints  the 
PM  and  the  PM  Is  given  the  authority  and  necessary  resources 
to  manage  assigned  programs,  the  PM  must  manage  and 
Implement  the  program  with  the  aid,  advice,  and  coordination 
of  requiring.  Implementing,  and  supporting  activities' 
Program  Action  Officers  (PAO).  The  key  difference  between 
the  700-serles  and  800-serles  program  manager  Is  that  the 
800-serles  program  has  two  management  tools  which  are  more 
effective  than  those  available  to  the  700-serles  program 
manager.  First  la  the  differences  between  the  800-serles 
Integrated  Logistics  Support  Plan  (ILSP),  which  Is  part  of 
the  Program  Management  Plan  (PMP)  and  the  700-serles 
Logistics  Support  Plan  of  the  Information  Systems  Program 
Plan  (ISPP).  The  ILSP  Is  a  comprehensive  document  required 
by  APR  800-8  and  addresses  life  cycle  management  from  cradle 
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to  grave.  The  ILSP  Is  Section  9,  Logistics,  of  the  PMP,  and 
while  the  PMP  is  not  required  to  be  approved  by  HQ  USAF 
(unless  specifically  directed  in  the  PMD),  the  PMP  does 
require  input  and  concurrence  from  all  participating 
commands.  Another  important  point  is  that  Integrated 
Logistics  Support  is  programmed,  budgeted  and  funded  as  an 
integral  part  of  the  acquisition  program.  The  Logistics 
Support  Plan  of  the  ISPP  (700-serles)  is  developed  using 
guidance  from  APR  400-26,  Logistics  Support  for  Ground 
Communlcatlons-Electronlcs  (C-E)  Systems  and  Equipment. 
Specific  funding  is  not  provided  to  the  PM  or  APLC  for 
implementing  the  Logistics  Support  Plan.  The  second  key 
difference  is  that  of  Program  Management  Responsibility 
Transfer.  As  stated  earlier  APR’s  800-4  and  800-2  require 
detailed  PMRT  planning  and  execution.  The  700-serles 
regulations  do  not  directly  require  PMRT  planning  or 
execution,  but  only  address  PMRT  indirectly  through 
APR  400-26.^ 

Concerns  Pertaining  to  the  Acquisition  and  Life  Cycle 
Management  of  Standard  Communlcatlons-Computer  Systems 

A.  The  first  concern  that  can  be  derived  from  the 
discussion  in  this  Chapter  is  centered  around  program 
management.  As  stated  earlier  the  800-serles  program 
management  process  has  evolved  with  a  vertical  orientation 
and  been  refined  as  the  acquisition  process  changed.  The 
700-serles  program  management  is  still  evolving  and  instead 
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of  having  a  vertical  orientation  with  ultimate  respon¬ 
sibility  and  authority  In  the  PM,  It  retains  the  horizontal 
orientation,  with  diffused  responsibility  and  authority. 

The  concern  Is  that  the  horizontal  management  orientation 
places  the  PM  in  the  position  of  not  being  able  to  control 
his  or  her  program,  and  not  being  able  to  deliver  the  best 
acquired  and  life  cycle  managed  program.  With  the  hori¬ 
zontal  program  management  approach  to  acquisition  and  life 
cycle  management,  the  functional  support  remains  In  the 
functional  chain  of  command,  and  Is  therefore  subject  to  the 
inherent  functional  Influences  and  not  always  responsive  to 
or  supportive  of  the  PM.  700-serles  program  managers  who 
are  responsible  for  standard  systems  and  COTS  systems  face 
the  concern  stated  above.  The  relationship  and  Interface 
between  APLC  and  APSC  In  the  program  management  of  an  800- 
serles  acquired  programs  provides  an  example  how  the  above 
concern  can  be  reduced  or  eliminated.  AFSC  Is  usually 
designed  as  the  Implementing  command  and  APLC  Is  designated 
as  the  supporting  command.  In  the  process  of  program 
management  APLC  will  assign  a  Deputy  Program  Manager  for 
Logistics  (DPML)  or  an  Integrated  Logistics  Support  Manager 
(ILSM)  to  work  for  the  PM.  The  PM  Is  responsible  for  the 
accomplishment  of  the  Integrated  Logistics  Support  (ILS) 
functions  In  any  acquisition  program  (APR  800-2).  However, 
In  this  relationship  the  PM  assigns  all  or  part  of  the  ILS 
responsibility  to  the  DPML/ILSM,  and  retains  final 
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responsibility  and  authority  for  ILS.  The  DPML/ILSM 

receives  technical  support  from  the  Air  Logistics  Center 

(ALC)  work  force  (from  the  ALC  designated  as  final  support 

center)  to  ensure  all  follow-on  logistics  matters  are 

considered.  The  result  of  this  process  is  a  fully  funded 

program  with  dedicated  management.  The  PMs  for  standard  and 

"stove  pipe"  communlcatlons-computer  systems  acquisitions  do 

not  always  have  this  support  or  this  type  of  working 

relationship  with  the  supporting  command,  whether  AFLC  or 

another  command.  Successful  interface  between  700-serles 

implementing  and  supporting  activities  has  been  successful 

in  the  past  only  because  of  Intense  management  effort,  in 

8 

spite  of  the  horizontal  management  orientation. 

B.  The  sebond  concern  is  that  the  procedures  in  the 
700  and  800-serles  regulations,  while  they  have  the  iden¬ 
tical  purposes,  use  different  procedures  and  terminology. 

The  requirement  to  use  700  and  800-serles  regulations  are 
repeatedly  referenced  in  both  sets  of  regulations  with  often 
confusing  results.  While  there  is  evidence  that  the  regula¬ 
tions  are  slowly  being  revised  to  make  taskings  generic,  as 
an  example  APR  800-8  now  refers  to  Implementing,  supporting, 
and  using  commands  Instead  of  Just  APLC  or  APSC,  most  of  the 
remaining  800-8erles  and  700-serles  regulations  have  not 
been  standardized.  APR  700-4,  as  an  example,  refers  to 
implementing,  and  requiring  activities  and  host  commands 
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while  APR  800-2  refers  to  implementing  participating, 
supporting,  and  operating  commands.  (See  Appendix  for  more 
examples  of  differing  or  conflicting  definitions.) 

This  Chapter  has  described  DOD  and  USAP  policy 
concerning  communlcatlons-computer  system  acquisition  and 
life  cycle  management;  compared  the  procedures  of  the  700 
and  800-serles  regulations;  and  provided  concerns  about  the 
application  and  effectiveness  of  these  regulations.  The 
next  Chapter  will  look  at  the  evolution  of  standard  systems, 
their  application  at  base  level,  and  the  challenges  facing 
the  standard  systems,  manager  during  the  operational  and 
support  phase  of  the  system's  life  cycle. 
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CHAPTER  VI 


SYSTEMS  MANAGEMENT 

Introduction 

The  task  of  Life  Cycle  Management  (LCM)  of  standard 
base  level  communlcatlons-computer  systems  for  the  Air  Force 
Is  without  question  a  difficult  and  complex  task.  The  over¬ 
all  LCM  task  has  become  Increasingly  more  complex  as  the 
number  of  micro  and  mini  computers  which  support  standard 
base  level  functions  have  exploded  on  the  scene  at  bases 
throughout  the  Air  Force.  This  chapter  will  look  at  the 
evolution  of  standard  base  level  computer  systems  In  the  Air 
Force,  describe  the  current  base  level  communlcatlons- 
computer  systems  environment,  and  describe  the  players  In 
the  Life  Cycle  Nangement  process  along  with  their  associated 
responsibilities.  The  major  thrust  will  be  toward  the 
system  management  challenges  facing  the  Standard  Systems 
Manager  during  the  operational  and  support  phase  of  LMC, 
that  Is  after  the  standard  system  has  gone  through  the 
acqulslton  and  development  phases  and  Is  operational.  We 
will  focus  on  some  actual  LMC  experiences  related  to  the 
biggest  computer  acquisition  ever  In  the  government,  the 
Phase  IV  program  and  how  LCM  (or  system  management  as  It  Is 
now  called)  Is  being  applied  for  some  of  the  standard  mini 
and  micro  computer  systems.  After  examining  these  two 
situations,  we  will  try  to  provide  some  suggestions  for 
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applying  and  Implementing  life  cycle  or  system  management 
across  the  spectrum  of  large,  medium,  and  small  standard 
communlcatlons-computer  systems  which  make  up  today's  base 
level  environment.  (See  Figure  1) 

Organizational  Responsibilities 

Many  organizations  and  people  participate  In  the 
acquisition,  production,  operation,  and  maintenance  of 
standard  communlcatlons-computer  systems  throughout  the 
systems  life.  This  section  Identifies  some  of  them  and 
briefly  explains  their  responsibilities. 

A.  Assistant  Chief  of  Staff,  Systems  for 
Command,  Control,  Communications,  and  Computers  (AF/SC).  In 
1984,  an  Air  Force  reorganlatlon  created  the  Assistant  Chief 
of  Staff  for  Information  Systems  (AF/SI).  At  the  same  time 
the  Air  Force  changed  the  way  It  managed  Its  base-lvel  Data 
Processing  Centers  (DPC)  and  Telecommunications  Centers 
(TCC).  Under  the  new  concept,  base-level  data  processing 
and  communications  responsibilities  were  combined  Into  a 
single  organization.  In  1986,  AF/SI  was  renamed  the 
Assistant  Secretary  for  Command,  Control,  Communications, 
and  Computers  (AF/SC).  AF/SC  Is  an  adjunct  to  the  Office  of 
the  Chief  of  Staff.  It  la  Independent  of  the  basic  Air 
Staff  structure  and  Is  responsible  directly  to  the  Air  Force 
Chief  of  Staff.  AF/SC  advised  and  supports  the  Chief  of 
Staff  and  Air  Staff  regarding  command,  control, 
communications,  and  computers  and  serves  as  the  HQ  USAF 
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Functional  Manager  for  Conmunlcatlons-Computer  Systems.  The 
salient  AP/SC  authorities  and  responsibilities  regarding 
communlcatlons-computer  systems  Include: 

1.  Produces  doctrine,  objectives,  con¬ 
cepts,  plans,  policies,  standards,  and  procedures  for 
communlcatlons-computer  systems. 

2.  Develops  and  maintains  the  Air  Force 
communlcatlons-computer  architectures.  Initiates  communl¬ 
catlons-computer  systems  Interoperability,  Inter- 
connectlvlty,  and  integration  actions  to  Improve  security, 
survivability,  endurance,  operational  capabilities,  and 
readiness  of  Air  Force  communlcatlons-computer  systems. 

3«  Ensures  communlcatlons-computer  sys¬ 
tems  resource  requirements  are  Identified  and  considered  In 
the  programming  and  budgeting  activities. 

4.  Reviews,  directs,  changes,  and  termi¬ 
nates  system  requirements,  directives,  plans,  and  other 
documents  to  obtain  effective  and  efficient  mission  support. 

5.  Designates  organization's  respon¬ 
sibility  for  management  of  standard  communlcatlons-computer 
systems.  MAJCONs  must  submit  requirements  affecting 
standard  communication-computer  systems  to  the  appointed 
manager  for  review  and  coordination  prior  to  approval. 

6.  Directs  Air  Force  participation  In 
government  Information  processing  standards  programs. 
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B.  Air  Force  Communications  Command.  APCC  Is 

a  critical  support  conmiand  with  over  58,000  people  providing 

support  to  every  other  Air  Force  operational  and  support 

command.  A  principal  AFCC  mission  Is  to  provide 

commu/il cations  and  computer  support  for  the  Air  Force,  other 

2 

agencies,  and  designated  command  and  control  systems.  AFCC 
Is  responsible  for  managing  the  design,  production,  acqui¬ 
sition,  and  life-cycle  operation  and  maintenance  of  standard 
communlcatlons-computer  systems.  The  salient  respon¬ 
sibilities  regarding  communlcatlons-computer  systems 
Include: 

1.  Develops  policies,  plans,  and  budgets 
for  communlcatlons-computer  systems. 

2.  Centrally  manages  standard  communl¬ 
catlons-computer  systems  from  the  conceptual  phase  through 
the  end  of  the  operational  phase. 

3«  Analyzes  existing  and  proposed  commu¬ 
nlcatlons-computer  systems  and  satisfies  operational 
requirements  by  making  optimum,  economic  use  of  technology 
and  achieving  compatibility  with  other  communlcatlons- 
computer  systems. 

4.  Directs  subordinate  units  responsible 
for  providing  support  for  standard  communlcatlons-computer 
systems  that  Includes  analysis,  procurement,  design, 
production,  test,  operation,  and  maintenance.  Satisfies  HQ 
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USAP-approved  Integration  and  Interface  requirements  for 
assigned  communlcatlons-computer  systems. 

5.  Directs  subordinate  units  respcrslble 
for  serving  as  the  Air  Force  central  acquisition  agencies 
for  computer  systems. 

C,  MAJCOM  Communlcatlons-Computer  System  Divi¬ 
sions.  All  MAJCOMs,  with  the  exception  of  Air  Force 
Logistics  Command  (AFLC)  and  Alaskan  Air  Command  (AAC),  have 
an  AFCC  Communlcatlons-Computer  Systems  Division  assigned  to 
operate^  maintain^  plan  and  program  for  AFCC  communl- 
catlons-computer  facilities  and  services  supporting  the 
respective  MAJCOM.  Each  la  an  AFCC  Division — an  Inter¬ 
mediate  command,  reporting  directly  to  the  Commander,  AFCC. 
Each  serves  as  the  MAJCOM  Deputy  Chief  of  Staff  for  Communl- 
catlons-Computer  Systems  to  be  sure  MAJCOM  Interests  are 
adequately  represented  In  Intercommand/agency  discussions  on 
MAJCOM  Issues.  These  divisions  commemd  assigned  personnel 
and  units  that  provide  base  communlcatlons-computer  system 
services  on  bases  within  the  MAJCOM.  The  MAJCOM  exercises 
operational  control  over  those  systems  operated  by  AFCC 
oz*ganlzatlons  for  the  exclusive  support  of  the  MAJCOM. 
Similarly,  the  host  wlng/base  commander  exercises  opera¬ 
tional  control  over  those  facilities  operated  by  an  AFCC 
organization  for  the  exclusive  support  of  the  base  and  Its 
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tenants. 


D.  Standard  Systems  Center  (SSC).  The  St2mdard 
Systems  Center  (SSC)  Is  an  Intermediate  headquarters  of 
AFCC.  It  provides  for  the  acquisition,  design,  production, 
and  life-cycle  management  of  stemdard  commxmlcatlons- 
computer  systems  at  bases  aiid  major  commands  world-vrlde. 

The  standard  communlcatlons-computer  systems  noz*mally 
assigned  bo  SSC  are  those  used  by  more  than  one  Air  Force 
major  command.  The  SSC  Commander  Is  the  Standard  Communi¬ 
cations  System  Manager  (SCSM)  for  all  standard 
communlcatlons-computer  systems  assigned  to  S3C.^  SSC  Is 
located  at  Gunter  Air  Force  Station  In  Montgomery,  Alabama. 
SSC  evolved  from  the  Supply  Systems  Design  Office  and  the 
Maintenance  Systems  Design  Office  In  the  early  1960s,  the 
Data  Automation  Design  Office  (I963  “  1967),  the  Air  Force 
Data  Systems  Design  Center  (I967  *  1984)  and  the  Air  Force 
Teleprocessing  Center  (1984  -  1986).  The  SSC  provides 
support  for  standard  communlcatlons-computer  systems  from 
the  conceptual  phase  through  the  end  of  their  operational 
life  cycle.  SSC  provides  communlcatlons-computer  systems 
acquisition,  production,  maintenance,  and  operations 
support.  SSC  has  one  subordinate  office  located  at  Tinker 
AFB  and  four  subordinate  directorates  located  at  Gunter  APS 
which  are  each  directed  by  a  Deputy  Chief  of  Staff  (DCS). 
Each  DCS  organization  Is  briefly  discussed  below. 

1.  The  Requirements  and  Programs  Direc¬ 


torate  Is  the  focal  point  for  communlcatlons-computer  system 


requirements.  It  analyzes  Information  system  requirements 
of  standard  and  related  systems  to  Identify  alternatives  for 
new  requirements  and  to  determine  system  Integration  and 
optimization  opportuntles. 

2.  The  Acquisition  Directorate  Is  a  pro¬ 
gram  management  organization  that  acquires,  produces,  and 
Implements  standard  computer  and  communications  hardware  and 


software  systems.  Acquisition  examples  Include  the  multl- 
bllllon  dollar  Phase  IV  program  and  the  recently  cancelled 
$100-mllllon  Inter-Servlce/Agency  Automated  Message  Pro¬ 
cessing  Exchange  Program  (I-SA  AMPE)  to  replace  large 
portions  of  the  Defense  Communications  Systems  (e.g., 

AUTODIN  switches).  Other  program  management  and  acquisition 
efforts  Include  the  Core  Automated  Maintenance  System 
(CAMS),  the  Air  Force  Command  and  Control  System  (APC2S)  and 
the  Defense  Data  Network  (DDN).  Upon  completion  of  an 
acquisition.  Program  Management  Transfer  of  Responsibility 
(PMRT)  occurs  to  a  life-cycle  manager  or,  as  currently 
defined,  a  Standard  Systems  Manager.  For  base-level  Infor¬ 
mation  systems,  this  Is  normally  the  Maintenance  and  Modifi¬ 
cations  Directorate  within  SSC.  This  directorate  has  repre¬ 
sentatives  from  functional  areas  assigned  to  work  with 
computer  and  acquisition  specialists  to  be  sure  the  systems 
provided  satisfy  user  requirements.  These  specialists 
assist  the  respective  functional  areas  In  translating  their 
requirements  Into  Implementable  program  plans. 

^3 


3.  The  Maintenance  and  Modifications 
Directorate  has  an  Air  Force-wide  mission  to  maintain  soft¬ 
ware,  documentation,  and  procedures  for  standard  information 
systemp.  Representatives  from  over  30  functional  areas  work 
with  computer  specialists  in  maintaining  the  standard  soft¬ 
ware,  providing  telephone  assistance,  emd  when  necessary, 
providing  on-site  assistance  to  users  Air  Force  wide. 

Systems  Include  large  and  small  systems  for  such  functional 
areas  as  supply,  maintenance,  operations  and  mobility,  civil 
engineering,  accounting  and  finance,  and  others.  It  is 
important  to  note,  for  purposes  of  this  paper,  that  it  is 
the  Maintenance  and  Modifications  Directorate  that  causes 
the  SSC  to  differ  significantly  from  a  typical  Air  Force 
Systems  Command  (AFSC)  product  division.  Responsibility  for 
a  software  system  created  or  acquired  by  the  SSC  Acquisition 
Directorate  normally  transfers  to  the  Maintenance  and 
Modifications  Directorate.  On  the  other  hand,  AFSC  product 
divisions  transfer  responsibility  to  AFLC  or  another  major 
command  for  software  support.  This  software  maintenance 
relationship  with  the  Acquisition  Directorate  will  be 
discussed  in  more  detail  later  on  in  this  chapter. 

4.  The  Systems  Support  Directorate  per¬ 
forms  life-cycle  management  of  standard  communlcations- 
computer  systems  at  bases  and  major  commands  wordlwlde.  The 
spectrum  of  systems  range  from  small  microcomputers  to  large 
main  frame  computer  systems.  These  computers  provide  the 
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core  computer  hardware  components  for  the  Air  Force  Communl- 
cations-Computer  Systems  Architecture  Infrastructure.  This 
Directorate  normally  assumes  system  management  respon¬ 
sibility  for  computer  systems  from  the  DCS  for  Acquisition 
after  the  computer  system  has  been  Implemented  In  the  opera¬ 
tional  environment.  In  fact,  the  commander  of  the  SSC,  has 
delegated  to  this  DCS  the  responsibility  of  System  Manager 
for  all  the  standard  communlcatlons-computer  systems 
assigned  to  the  Standard  Systems  Center.^  As  the  life-cycle 
manager,  or  the  Standard  Systems  Manager,  this  DCS  serves  as 
the  single  overall  manager  of  assigned  standard  communi¬ 
cations  computer  systems  responsible  for  all  aspects  of 

6 

systems  support,  as  well  as  any  system  changes.  This 
Directorate  also  performs  quality  assurance,  system  testing, 
and  preparation  and  distribution  of  software  and  documen¬ 
tation  to  bases  around  the  world.  The  customer  support  unit 
provides  2M-hour-a-day,  7~day-a-week  telephone  assistance  to 
users  of  standard  systems  around  the  world.  On  an  average 
day,  this  office  handles  200-300  telephone  calls.  Also, 
this  office  handles  problems  that  are  less  urgent  using  a 
formal  difficulty  reporting  (DIREP)  and  feedback  system.  It 
must  be  noted  that  these  customer  support  functions  are 
performed  only  for  those  standard  computer  system  appli¬ 
cations  which  operate  In  the  base  level  Data  Processing 
Center  (DPC)  on  the  shared  base  level  computer,  l.e.,  the 
Phase  IV  UNISYS  ll60.  For  the  dedicated  functional  systems 


that  operate  on  the  small  or  medliun  mini  or  microcomputers, 
such  as  the  Zenith  or  Wang  computers,  these  customer  support 
functions  are  handled  by  the  personnel  dedicated  to  the 
particular  functional  system. 

5.  The  Command  and  Control  Systems  Office 
(CCSO)  at  Tinker  AFB,  Oklahoma  provides  computer  hardware 
and  software  programming  for  command  and  control,  tel<“- 
communlcatlons,  air  traffic  control,  and  meteorological 
systems.^  This  Includes  20  major  software  systems  worldwide 
on  l8  different  computer  systems.  The  management  of  these 
systems  are  not  discussed  In  this  paper. 

E.  Base-Level  Communlcatlons-Computer  Systems 
Squadron  (CSS).  The  base-level  CSS  manages  and  operates 
communlcatlons-computer  systems  and  air  traffic  control 
facilities  for  the  base.  The  Data  Processing  Center  (DPC) 

Is  one  of  the  many  functions  within  the  CSS.  The  DPC  Is  a 
service  organization  providing  computer  support  to  virtually 
every  base-level  functional  area.  The  user  requirements 
normally  dictate  a  24-hour,  7~day-a-week  operation.  The  DPC 
normally  has  two  sections.  The  systems  control  section 
works  with  the  functional  users  In  scheduling  computer 
support,  receiving  Input,  providing  processing  results,  and 
providing  data  processing  consultation  services.  The  opera¬ 
tions  section  usually  operates  the  computers  that  produce 
the  Information  needed  by  the  functional  areas.  While  this 
paper  focuses  on  standard  Information  systems,  note  that  the 
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base  CSS*  as  does  APCC,  has  responsibility  for  base-unique 
computer  systems,  telephone  systems,  word  processing  equip¬ 
ment,  microcomputers,  telecommunications  systems,  long-haul 
communications  systems,  crypto  equipment,  weather  facsimile 
equipment,  mobile  radios,  and  public  address  systems. 
Further,  the  CSS  has  responsibility  for  the  air  traffic 

p 

control  facilities. 

Base  Level  Data  Automation  Standardization 

The  standardization  of  automated  base  level 
processing  has  evolved  over  25  years.  It  started  In  1962 
with  the  standardization  of  the  base  level  supply  system 
using  the  UNIVAC  1050  computer.  Standardization  of  auto¬ 
mated  systems  for  other  base  level  support  functions  such  as 
finance,  personnel,  maintenance,  medical  supply,  and  others 
began  In  the  late  1960s,  The  phases  of  this  standardization 
are  shown  below. 


PHASE 

FIRST 

INSTALLED 

REPLACED 

OLD 

COHPUTER 

NEW 

COMPUTER 

DESCRIPTION 

I 

1964 

1983 

PCAM 

UNIVAC 

1050 

Automate  SBSS 

II 

1968 

1986 

Burroughs 

263 

Burroughs 

3500/4700 

Automate 

remaining 

base-level 

functions 

III 

1968 

TBD 

Honeywel 1 
200/800 

Honeywel 1 
6000 

Modernize 

MAJCOM 

computer 

support 

IV 

1983 

TBD 

UNIVAC 

1050  ft 
Burroughs 
.  3500/4700 

UNISYS 

SHOO  ft 

Sll 

Provide  new 
computers  to 
replace  old 

Phase  I  and  II 
computers 

SCRC 

1983 

1986 

Zenith 

Z120 

Zenith 

Z248 

Provide 
standard 
microcomputer 
hardware  ft 
software 

Follow-on  1986 
SCRC 

TBD 

Zeni  th 

Z120 

Zenith 

Z248 

Provide 

standard 

microcomputer 
hardware  ft 
software 


Before  standardization  policies  were  established. 


each  command  independently  implemented  unique  procedures  and 
capabilities  to  satisfy  their  needs  and  the  overall  policies 
established  by  HQ  USAF.  Shortcomings  associated  with  this 


non-standax*dlzatlon  Included  Increased  training  for 
personnel  rotated  between  commands,  hampered  deployments, 
and  duplication  of  effort.  Benefits  resulting  from 
stand2u:‘dlzatlon  Included  reductions  In  costs  and  man-hours 
associated  with  the  design  production.  Implementation,  and 
operation  of  the  systems. 

The  major  standardization  emphasis  today  Is  to  use 
hardware  and  software  components  from  standard  Air  Force 
contracts.  These  Include  the  Base-Level  Data  Automation 
Program  (Phase  IV)  contract  awarded  to  Sperry,  the  Small 
Computer  Requirements  Contracts  (SCRC)  awarded  to  Zenith, 
and  the  Air  Force  Minicomputer  Multi-User  System  (AMMUS) 
contract  awarded  to  Wang.  These  contracts  provide  powerful 
forces  that  encourage  standardization.  They  also  reduce  the 
complexity  normally  associated  with  a  new  communlcatlons- 
computer  system.  The  user  does  not  have  to  be  concerned 
with  the  hardware,  maintenance,  commercial  software, 
training,  pricing,  and  contract  terms  and  conditions.  The 
user  can  concentrate  on  the  requirements,  fundings,  software 
development,  and  the  Implementation.  Where  appropriate,  the 
user  can  test  the  proposed  solutions  to  his  requirements  In 
a  operational  prototype  environment  at  Mather  AFB.  Since 
these  contracts  form  the  basis  for  current  and  future  base 
level  standard  communlcatlons-computer  systems,  and  which 
collectively  represent  significant  life-cycle  management  or 
system  management  challenges  for  the  Standard  System 
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Managers,  these  contracts  and  associated  systems  are 
described  below. 

A.  Base-Level  Data  Automation  Program 
(Phase  IV).  Phase  IV  Is  the  largest  computer  acquisition 
ever  attempted  by  the  US  government.  The  overall  objective 
of  the  Phase  IV  program  Is  to  provide  standard,  cost- 
effective,  responsive,  and  reliable  computer  support  for  a 
variety  of  Air  Force  base-level  functions.  The  Phase  IV 
contract  Is  the  primary  source  for  satisfying  base-level 
computing  needs  other  than  those  using  microcomputers.  It 
Is  used  for  (1)  automation  functions  supporting  wing-level 
and  below  on  a  base,  or  (2)  a  function  which  requires  use  of 
existing  Phase  IV  software.  Phase  IV  Is  planned  to  be  a 
care  component  of  the  base-level  communlcatlons-computer 
system  architecture  until  the  year  2002.  A  total  of  229 
Burroughs  and  UNIVAC  computer  systems  were  replaced  with  155 
Sperry  Phase  IV  computer  systems  at  119  locations.  The 
Phase  IV  system  (a  Sperry  1100  computer)  provides  an  Infra¬ 
structure  that  can  grow  as  needed  to  accommodate  Increasing 
processing  requirements  for  up  to  20  years  (1983  up  to 
2002).  In  May  I986,  the  Implementation  of  Phase  IV 
computers  was  completed  at  all  Air  Force  bases. 

The  Phase  IV  system  Is  a  large  manlnframe  computer 
and  It  provides  centralized  computer  support  to  base  level 
users  at  active  Air  Force,  Air  Force  Reserve,  and  Air 
National  Guard  Installations.  Base  level  users  Include 
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areas  such  as  base  supply >  maintenance,  accounting  and 
finance,  personnel,  civil  engineering,  and  other  base  level 
activities.  The  computer  software  that  operates  on  the 
Phase  IV  system  Is  considered  Air  Force  steindard  software  In 
that  the  exact  same  software  runs  at  every  computer  location 
throughout  the  Air  Force.  This  Includes  active.  Reserve  and 
Guard  units.  With  the  exception  of  the  personnel  system, 
the  computer  software  for  the  Phase  IV  Is  centrally  deve¬ 
loped  and  distributed  by  the  Standard  Systems  Center  at 
Gunter  AFS,  Alabama.  (The  SSC  organization  was  described 
earlier  In  this  chapter.)  The  SSC  Is  also  responsible  for 
administering  the  Phase  IV  contract  and  serves  as  the  Phase 
IV  Standard  Communlcatlons-Computer  System  Manager. 

B.  Small  Computer  Requirements  Contracts. 
Micro-computers  are  critical  components  of  Air  Force  Infor¬ 
mation  processing.  Air  Force  policy  requires  stand-alone 
small  computer  resource  requirements  to  be  satisfied  from 
existing  small  computer  requirements  contracts.  This 
Includes  word  processing  and  office  automation  requirements. 
Waivers  to  this  policy  must  be  approved  by  HQ  USAF/SCT. 
Standard  requirements  contracts  currently  exist  for  micro¬ 
computers  and  lapbeld  microcomputers.  In  addition  to  these, 
the  Air  Force  Is  also  planning  to  award  a  multiuser  small 
computer  requirements  contract  by  early  1988.  Air  Force-^ 
wide  standardization  actions  for  microcomputers  have 


produced  tremendous  benefits.  Along  with  the  Phase  IV 


contract,  these  small  computer  requirements  contracts 
provide  the  core  computer  hardware  components  for  the  Air 
Force  Communlcatlons-Computer  Systems  Architecture  Infra¬ 
structure.  The  benefits  the  standard  computer  contracts 
Include  Improved  standardization.  Integration,  Inter¬ 
operability  with  significant  reductions  In  hardware,  soft¬ 
ware,  and  acquisition  costs  and  time  required  for 
acquisition.  Some  additional  background  and  status  Infor¬ 
mation  on  the  small  computer  contracts  Is  provided  below. 

1.  In  May  1982,  the  Air  Force  established  an 
Air  Force  small  computer  office  at  the  Standard  Systems 
Center  to  foster  Air  Force-wide  standardization  of  hardware, 
software,  maintenance,  physical  Interfaces,  and  communi¬ 
cations  Interfaces.  This  office  became  the  single  Air  Force 
focal  point  for  establishing  and  managing  standard  small 
computer  contracts.  In  October  1983,  the  Air  Force  and  Navy 
Jointly  awarded  Zenith  Corporation  the  first  Small  Computer 
Requirements  Contract  (SCRC)  for  microcomputers.  The 
contract's  objectives  were  to  obtain  competitive  pricing, 
standardize  the  microcomputers  In  the  Air  Force  Inventory, 
and  streamline  the  ordering  process  to  make  It  easier  for 
users  to  obtain  microcomputers.  The  Initial  contract  was 
extended  In  March  1984  and  again  In  November  1984.  A 
follow-on  SCRC  was  competively  awarded  to  Zenith  Corporation 
In  1986.  Up  to  90,000  IBM-PC  compatible  microcomputers 
(Z248s)  will  be  purchased  from  this  contract.  These 
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nlcrocomputers  have  shown  that  they  can  be  powerful  tools 
for  Increasing  productivity  and  reducing  costs.  Today  they 
are  being  used  for  a  wide  variety  of  functions  such  as  word 
processing,  suspense  tracking,  and  planning  of  maintenance 
and  flying  schedules. 

2.  The  relatively  simple  process  for  obtaining 
small  computers  and  associated  software  was  explained  above. 
Each  MAJCOM  has  Small  Computer  Technical  Centers  (SCTC)  to 
encourage  sharing  of  software,  provide  assistance  to  users, 
and  to  avoid  spending  resources  to  produce  software  that  Is 
available  elsewhere. 

C.  Air  Force  Minicomputer  Multi-User 
System  (AMMUS).  This  contract  waa  awarded  to  Wang 
Corporation  In  January  1986.  It  allows  for  up  to  1,600 
large  minicomputers  and  associated  equipment  (e.g., 
printers,  workstations)  and  software  (e.g.,  word  processing 
graphics)  to  be  purchased.  The  contract  can  cover  an  8-year 
period  for  the  purchase  of  computers  and  another  3-years  for 
malnteneuice  of  the  equipment.  The  major  requirements  for 
this  contract  were  the  Work  Information  Management  System 
(WINS),  Service  Information  Management  System  (SIMS),  Base 
Contract  Administration  System  (BCAS),  euid  Air  Force 
Commissary  Service  system.  The  Air  Force  Computer  Acqui¬ 
sition  Center  administers  this  contract.  However,  the 
Standard  Systems  Center  has  responsibility  for  configuration 
management  and  requirements  processing. 
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D.  Air  Force  Standai»d  Multiuser  Small 
Computer  Requirements  Contract  (SMSCRC).  The  systems  that 
will  be  available  from  this  contract  will  either  be  super- 
micro-computers  or  small  minicomputers  capable  of  supporting 
from  two  to  64  users.  Access  to  the  computers  will  be 
through  standard  microcomputer  terminals.  It  Is  anticipated 
that  the  Air  Force  will  buy  about  22,000  multiuser  computers 
from  this  five-year  contract.  A  primary  use  of  this 
computer  will  be  to  satisfy  office  automation  requirements 
throughout  the  Air  Force.  The  SMSCRC  Request  for  Proposal 
was  released  to  Industry  In  March  1987.  The  contract  Is 
expected  to  be  awarded  by  early  1988.^^  The  SMSCRC  contract 
Is  being  administered  by  the  Air  Force  Computer  Acquisition 
Center.  Configuration  management  and  requirements 
processing  Is  the  responsibility  of  the  Standard  Systems 
Center. 

Modernization  and  Future  Base-Level  Systems 

As  Indicated  earlier,  the  last  Phase  IV  system  was 
successfully  Implemented  In  May  1986.  Through  the  Implemen¬ 
tation  phase  an  effort  was  Initiated  to  modernize  the 
functional  automated  data  systems  (ADSs)  on  the  large  main 
frame  Phase  IV  system.  This  modernization  effort  was  to 
Improve  the  efficiency  and  productivity  of  the  ADSs  using 
the  capabilities  provided  with  the  new  Phase  IV  computer. 
Parallel  with  the  modernization  efforts  many  functional 
areas  took  advantage  of  the  capabilities  offered  by  the  mini 
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and  microcomputers  requirements  contracts  and  moved  their 
standard  functional  ADSs  off  the  shared  main  frame  system  to 
the  smaller  computers.  The  software  modernization  efforts 
will  continue  for  these  applications  on  the  SHOO  to  make 
the  software  more  effective  and  productive.  Also,  those 
standard  systems  which  have  moved  to  the  small  computer 
systems  will  continue  to  Install  and  maintain  their  existing 
systems  as  well  as  continue  to  Incorporate  new  validated 
mission  requirements. 

The  current  and  future  trend  of  the  functional  areas 
to  move  their  standard  systems  to  the  minis  and  micros  has 
altered  the  original  concept  of  using  the  single  mainframe 
Phase  IV  computer  as  the  central  point  for  providing  base 
level  computer  support  to  all  functional  areas.  As  a 
result,  there  has  been  a  significant  Impact  on  the  planned 
system  tti£uiageaent  approach  for  base  level  systems.  Instead 
of  having  to  manage  a  single  mainframe  system,  there  are  the 
minis  and  micros  which  must  be  managed  too.  The  present  day 
mix  of  computer  systems  and  those  projected  for  the  future 
pose  significant  system  management  challenges  for  standard 
base  level  commimlcatlons-computer  system  managers.  (See 
Figure  2)  To  provide  an  Insight  Into  these  challenges,  we 
will  review  what  was  originally  envisioned  for  applying 
system  management  to  the  Phase  IV  system  along  with  a  look 
at  some  things  which  have  Impacted  the  original  concept. 
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FUTURE  SYSTEMS 


HOW  - 

FUTURE _ 

TO  BE  DETERMINED  TBD 


After  looking  at  Phase  IV,  we  will  look  at  how  system 
management  functions  are  being  addressed  for  the  small  mini 
and  micro  dedicated  systems. 

Systems  Management  Base-Level  Systems 
A.  Large  Mainframe  Systems. 

Prior  to  Phase  IV,  Automated  Data  Processing 
Systems  (ADPS)  Management,  or  systems  management  as  It  Is 
now  called,  for  the  base-level  computer  systems  (Burroughs 
3500/3700)  was  centralized  at  the  Air  Force  Data  Systems 
Design  Center  (AFDSDC).  As  the  USAP  ADPS  manager,  APDSDC 
was  charged  with  the  overall  management  of  the  Base  Level 
Data  Automation  Standardization  Program.  These  respon¬ 
sibilities  Included  establishing  and  maintaining  a  Configu¬ 
ration  Management  System  for  processing  changes  to  the  ADPS; 
reviewing  all  major  command  requirements,  and  plans  for 
computer  systems  to  ensure  compatibility  with  the  standard 
systems;  developing  and  maintaining  standard  software 
systems  to  support  functional  users;  maintaining  a  field 
assistance  office  to  provide  solutions  to  problems  Identlfed 
by  users  at  the  bases;  maintaining  standard  systems  software 
provided  by  the  commercial  vendor  (Burroughs  Corporation); 
researching  and  Identifying  hardware  requirements  to  support 
future  base  level  automated  processing  requirements;  serving 
as  the  focal  point  for  discussing  with  vendors  hardware  and 
software  performance,  equipment  reliability,  and  new  vendor 
products;  maintaining  a  configuration  analysis  and 
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projection  system  which  provides  a  description  of  current 
and  projected  workload  requirements  at  all  base  data 
processing  centers,  to  Include  equipment  configuration, 
projected  equipment  upgrades,  equipment  costs,  equipment 
maintenance  data,  as  well  as  facilities  and  communications 
information;  maintaining  a  data  base  on  each  Data  Processing 
Center  which  provides  an  Inventory  and  associated  costs  of 
all  hardware,  an  Inventory  of  all  standard  and  unique  soft¬ 
ware  processed  by  the  DPC  or  scheduled  to  be  Implemented,  a 
historical  workload  profile  by  system,  a  list  of  projected 
hardware  changes,  a  list  of  required  and  available  physical 
space  capacity  for  the  system,  the  location  and  user  of  all 
remote  hardware,  and  system  utilization  data  down  to  the 
component  level. 

As  the  foregoing  Indicates,  the  number  and  type  of 
life  cycle  or  ADPS  management  functions  Is  extensive.  The 
bulk  of  the  responsibility  for  these  system  management 
functions  was  centralized  at  the  APDSDC  In  the  Directorate 
of  ADPS  Management.  This  Directorate  also  served  as  the 
focal  point  for  all  liaison  with  the  Air  Force  Automated 
Systems  Program  Office  (APASPO)  during  the  acquisition  and 
development  phases  of  the  Phase  IV  Program.  As  the 
Installation  of  the  Individual  Phase  IV  systems  was 
completed  and  became  operational,  systems  management  respon¬ 
sibility  for  the  individual  systems  was  to  pass  from  the 
APASPO  to  the  Directorate  of  ADPS  Management.  The 
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Directorate  of  ADPS  Management  was  to  pick  up  all  the  systems 
management  functions  described  above  for  all  the  newly 
Installed  systems,  and  once  all  the  Phase  IV  systems  were 
Installed  and  operational.  Program  Management  responsibility 
was  to  transfer  from  the  commander  of  the  APASPO  to  the 
APDSDC.  The  APDSDC  was  to  have  complete  responsibility  for 
all  the  Phase  IV  life-cycle  management  (or  systems  manage¬ 
ment)  functions.  It  was  to  be  the  focal  point  for  all 
actions  affecting  the  life-cycle  of  the  Phase  IV  system. 
However,  several  things  occurred  which  significantly 
Impacted  the  life-cycle  management  or  systems  management  of 
the  Phase  IV  systems. 

During  the  Implementation  phase  of  the  Phase  IV 
program,  at  least  two  reorganizations  took  place  which  saw 
the  APDSDC  and  the  APASPO  cease  to  exist  as  separate  organi¬ 
zations.  It  Is  not  necessary  to  provide  the  details  of  the 
reorganization  other  than  to  point  out  that  these  two 
organizations  were  dissolved  and  after  a  couple  of 
Iterations  the  Standard  Systems  Center  was  created.  How¬ 
ever,  It  should  be  noted  that  a  prime  objective  of  the 
Commander,  Air  Force  Communications  Command,  for  the 
reorganization  was  to  provide  "a  thorough  requirements 
review  process"  and  to  "create  a  logical  flow  from  require¬ 
ment  through  production  to  operation  and  maintenance.^^ 

During  the  reorganization  process,  several  factors 
had  significant  Impact  on  life  cycle  management  for  Phase 
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IV:  (1)  acquisition  functions  were  merged  with  system 
development  and  maintenance  functions,  (2)  system  mainte¬ 
nance  and  field  support  functions  were  split  organiza¬ 
tionally,  (3)  ADPS  management  (Systems  Management)  functions 
were  split  across  different  directorates,  (4)  the  Phase  IV 
contract  was  revised  to  allow  major  commands  to  buy  directly 
off  the  Phase  IV  contract,  (5)  the  automated  systems  used  to 
support  pre-Phase  IV  ADPS  management  functions  such  as 
configuration  management,  hardware  Inventory,  and  software 
control  and  distribution,  were  not  available  post-Phase  IV; 
and  (6)  execution  of  the  Phase  IV  Program  Management  Respon¬ 
sibility  Transfer  (PMRT)  Plan  resulted  In  a  large  amount  of 
Phase  IV  program  acquisition  and  Implementation  related 
documentation  being  transferred  to  the  DCS  for  Systems 
Support,  which  organizationally,  they  were  not  prepared  to 
accept.  There  was  considerable  confusion  as  to  what 
functions  were  to  be  transferred  to  whom.  Furthermore, 
unlike  the  APSC/APLC  relationship  In  weapon  system  acqui¬ 
sitions,  none  of  the  personnel  Involved  In  the  upfront 
acquisition  and  Implementation  efforts  transferred  with  the 
program. 

What  Is  the  significance  of  all  this?  Very  simply. 
It  has  had  a  serious  Impact  on  the  ability  of  the  Standard 
Systems  Manager  for  Phase  IV  systems  to  carry  out  his  system 
management  responsibilities.  Take  for  example,  the  lack  of 
automated  tools  to  provide  system  management  functions  such 
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as  configuration  management  and  hardware  and  inventory 

accountability.  Without  such  tools  it  is  virtually 

impossible  to  track  what  equipment  has  been  ordered. 

Installed  and  accepted  at  the  bases  and  it  is  very  difficult 

to  answer  questions  such  as  "How  much  money  have  we  spent  on 

Phase  IV  equipment?"  You  cannot  answer  this  type  of 

question  without  a  massive  and  lengthy  paperwork  exercise 

and  even  then  the  answer  is  basically  nothing  less  than  a 

best  estimate. Another  example  is  the  Phase  IV  contract 

change.  This  change  allowed  the  major  commands  to  buy 

equipment  directly  from  Sperry.  However,  they  are  supposed 

to  have  all  such  orders  approved  by  the  Standard  Systems 
16 

Manager.  They  don't  always  do  this.  As  a  result,  equip¬ 
ment  is  Installed  on  the  "shared”  Phase  IV  system  at  bases 
without  the  knowledge  of  the  Standard  System  Manager.  This 
severely  limits  the  Standard  System  Manager's  ability  to 
effectively  assess  the  Impact  of  the  additional  workload  on 
the  performance  of  the  overall  system  with  any  degree  of 
accuracy.  Any  additional  workload  added  to  the  "shared" 
SHOO  system  without  being  fully  assessed  for  overall  system 
Impact  could  seriously  degrade  system  response  to  an 
unacceptable  level  where  functional  areas  would  not  be  able 
to  satisfy  mission  requirements.  Besides  systems  perfor¬ 
mance,  unilateral  equipment  acquisitions  by  the  major 
commands,  potentially  run  the  risk  that  the  price  they  pay 
for  the  equipment  may  not  be  the  best  price  for  the  govern- 
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ment.  The  evaluation  of  contractor  proposed  substitutions 
and  additions  are  continuous  activities  that  take  place 
between  the  Standard  Systems  Manager,  contractor,  and  the 
Procuring  Contract  Office  (PCO).  As  a  result,  the  Standard 
Systems  Manager  is  aware  of  potential  price  changes  which 
would  benefit  the  goveimment.  With  this  knowledge  he  can 
defer  or  delay  equipment  orders  until  price  negotiations 
between  the  PCO  and  contractor  are  complete,  thus  taking 
advantage  of  any  price  reductions.  Further,  there  have  been 
Instamces  where  unilateral  action  by  the  major  comannds  have 
resulted  in  the  purchase  of  new  equipment  when  excess  equip¬ 
ment  was  available.  If  the  major  command  had  coordinated 

with  the  Systems  Manager  (as  required  by  the  regulation)  the 

17 

major  command  would  have  saved  his  O&M  dollars. 

Besides  the  confusion  as  to  what  functions  would 
transfer  to  whom  and  the  fact  that  no  personnel  transferred 
with  the  program,  there  is  an  additional  aspect  of  the  Phase 
IV  Program  Management  Responsibility  transfer  that  bears 
mentioning.  There  was  not  a  full  transfer  of  program 
authority  and  responsibility.  While  Systems  Management 
responsibility  for  the  operational  Phase  IV  systems  was 
picked  up  by  the  DCS  for  Systems  Support  (without  any  addi¬ 
tional  resources)  the  DCS  for  Acquisition  continued  to 
retain  Program  Management  responsibility  for  major  hardware 
acquisitions  which  were  taking  place  off  the  Phase  IV 
contract,  namely  the  Transportable  Shelter  System  (TSS),  the 
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Core  Automated  Maintenance  System  (CAMS),  and  the  Remote  Job 
Entry  Terminal  Systems  (RJETS).  The  significance  of  this  Is 
that  the  responsibility  and  authority  for  systems  management 
of  the  standard  Phase  IV  system  Is  spread  between  the 
Stemdard  System  Manager  (DCS  for  Systems  Support)  for  the 
operational  systems,  and  the  Program  Manager(s)  (DCS  for 
Acquisition)  for  the  "add-on"  programs,  TSS,  RJETS  and  CAMS. 
It  Is  essential  that  the  Program  Managers  for  the  "add-ons" 
and  the  Standard  Systems  Manager  closely  Interact  to  ensure 
all  technical  decisions  are  made  with  full  consideration  of 
the  Impact  on  the  overall  Phase  IV  operational  system.  This 

V 

situation  clearly  Indicates  that  when  program  management 

actions  and  operational  management  actions  are  occurring  In 

parallel  for  a  single  program  It  Is  somewhat  difficult  to 

establish  "a  single  point  of  management,  during  every  phase 

of  system  life,  with  sufficient  authority,  responsibility, 

and  accountability  for  effective  management  and  operation  of 

the  system,"  as  Is  stated  as  Air  Force  Communlcatlons- 

Computer  Systems  Management  Policy.^®  Also,  one  of  the 

objectives  of  the  Standard  Systems  Center  reorganization  was 

to  "ensure  clear  accountability"  of  who  Is  In  charge  of 
19 

major  programs.  Clearly,  this  objective  was  not  achieved 
for  the  Phase  IV  Program. 

B.  Medium  and  Small  Systems. 

What  makes  the  application  of  Systems  Management 
different  for  small  and  medium  systems  over  the  large  main 
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freune  Phase  IV  SHOO  system?  Mainly,  the  Phase  IV  system  Is 
a  "shared”  system  where  computer  support  Is  provided  to 
multiple  functional  users.  As  a  shared  system.  It  serves  as 
a  center  of  gravity  for  each  base.  When  It  Is  not  operating 
properly,  every  functional  area  Is  affected.  By  being  a 
shaired  system,  the  Standard  System  Manager  for  the  Phase  IV 
systems  has  to  be  kept  knowledgeable  of  all  activities  which 
could  potentially  Impact  the  overall  system.  ■  As  new 
functional  data  systems  are  being  developed  for  the  shared 
SHOO,  or  major  changes  are  made  to  existing  functional  data 
systems,  the  Standard  System  Manager  must  actively  Interface 
with  the  various  ADS  Managers  throughout  the  software 
development  and  Implementation  process  to  Insure  that  the 
newly  developed,  or  revised  functional  software,  remains 
compatible  and  Interoperable  with  existing  systems,  and  In 
no  way  degrades  computer  support  to  any  other  functional 
user.  At  the  same  time  the  Phase  IV  Systems  Manger  must 
continually  Interact  with  the  Program  Managers  responsible 
for  the  acquisition.  Installation,  and  Implementation  of  the 
"add  on"  systems  which  are  being  acquired  off  the  Phase  IV 
contract.  Also,  he  needs  to  be  aware  of  any  hardware  being 
acquired  by  the  major  commands  as  well  as  any  major  command 
unique  software  applications  being  Implemented  on  the  shared 
system.  The  system  manager  must  be  In  the  loop  for  any 
actions  related  to  the  shared  system.  He  has  sole  responsi¬ 
bility  to  Insure  that  the  shared  system  (hardware  and 


systems  software)  continues  to  provide  equitable  support 
across  the  spectrum  of  functional  area  users. 

For  the  mini  and  micro  systems  a  somewhat  different 
situation  exists.  First,  as  Indicated  earlier,  the  big 
difference  Is  the  mini  and  microcomputer  systems  are  dedi¬ 
cated  systems  as  opposed  to  shared  systems.  They  are 
dedicated  In  the  sense  that  the  hardware  Is  dedicated  to  a 
single  functional  area.  No  other  functional  software 
operates  on  the  hardware,  that  Is,  It  Is  not  shared  with 
other  fxinctlonal  areas.  Figure  1,  shown  earlle.  ,  depicts 
various  functional  areas  (Engineers,  Contracting, 

Commissary,  Hospital,  Comptroller,  etc.)  and  the  dedicated 
hardware  (Wang,  Data  Point,  System  II,  National  Cash 
Register,  etc.)  they  use  for  computer  support. 

To  set  the  stage  for  discussing  system  management 
for  the  small  and  medium  computers,  we  need  to  briefly 
review  how  the  current  environment  evolved.  First,  as  we 
mentioned  earlier,  the  majority  of  the  current  functional 
applications,  which  now  operate  on  a  dedicated  mini  or 
microcomputer,  previously  operated  on  the  shared  system, 
that  Is  the  Burroughs  3500/3700  which  was  replaced  with  the 
Sperry  1100.  In  this  environment,  functional  area  personnel 
and  software  development  personnel,  under  the  direction  of 
an  ADS  Manager,  were  mainly  concerned  with  the  development 
and  maintenance  of  functional  software.  Life-cycle  manage¬ 
ment  or  system  management  responsibilities,  dealing  with 


contract  administration  and  configuration  management  of 
hardware  and  software,  was  centralized  under  a  single  ADPS 
Manager,  and  system  support  functions  such  as  quality 
assureince  testing,  control  and  distribution  of  software  and 
documentation  to  the  bases,  and  providing  field  assistance 
to  users  of  the  system  around  the  world,  were  performed 
mainly  by  support  personnel  assigned  outside  the  functional 
area.  Also,  we  need  to  keep  In  mind  that  the  Standard 
Systems  Center  evolved  and  was  organizationally  structured 
to  have  four  directorates  which  would  provide  the  management 
support  needed  to  sustain  a  communlcatlons-computer  system 
throxighout  Its  system  life,  l.e.,  the  DCS  for  Requirements 
and  Programs  for  requirements  validation;  the  DCS  for  Acqui¬ 
sition  for  managing  program  acquisition.  Installation,  and 
Implementation;  the  DCS  for  Maintenance  and  Modification  for 
maintaining  the  operational  functional  software;  and  the  DCS 
for  Systems  Support  for  providing  systems  management  (or 
llfe”cycle  management)  support  for  the  hardware  and  system 
software  during  Its  operational  life,  and  providing  customer 
support  functions.  As  a  system  evolves  through  the  require¬ 
ments  validation  phase,  responsibility  and  authority  for  the 
system  Is  to  move  from  the  DCS  for  Requirements  and  Programs 
to  the  DCS  for  Acquisition  for  program  management  related 
actions.  Following  Implementation  of  the  system,  software 
maintenance  responsibility  for  the  operational  functional 
software  would  move  to  the  DCS  for  Maintenance  and 
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Modification  while  program  management  responsibility  for 
life-cycle  management  of  the  operational  hardware  and  system 
software  would  move  to  the  DCS  for  Systems  Support. 

When  the  functional  areas  moved  their  applications 
off  the  large  shared  system  to  the  minis  and  micros,  they 
effectively  combined  program  management  and  system  manage¬ 
ment  responsibilities  with  their  already  existing  ADS 
management  responsibilities.  In  effect,  the  ADS  Manager 
picked  up  two  additional  management  hats,  one  of  a  Program 
Manager  and  one  of  a  System  Manager.  Not  only  did  he  remain 
responsible  for  maintaining  the  operational  functional  soft¬ 
ware  on  the  shared  system,  but  he  also  became  responsible 
for  the  program  management  actions  related  to  the 
Installation  of  the  mlcro/mlnl  hardware  along  with  the 
development  and  Implementation  of  the  new  functional  soft¬ 
ware  on  the  mlcro/mlnl.  After  the  new  mlnl/mlcro  hardware 
was  Installed  and  the  new  functional  software  on  the  micro/ 
mini  became  operational,  he  has  remained  responsible  for 
maintaining  the  functional  software  and  providing  all  the 
customer  support  and  field  assistance  functions.  In  effect, 
all  ADS  management,  program  management,  and  system  manage¬ 
ment  functions  are  being  performed  by  personnel  who 
previously  were  only  concerned  with  maintaining  an  opera¬ 
tional  automated  data  system  that  operated  on  a  shared 
computer. 
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An  example  of  where  management  for  a  dedicated  mini/ 


micro  system  has  been  combined  Is  the  standard  Base 
Contracting  Automated  System  (BCAS).  BCAS  Is  an  on-line 
system  which  operates  on  Wang  hardware  acquired  off  the  Air 
Force  Minicomputer  Multi-User  System  (AMMUS)  contract,  BCAS 
Is  a  replacement  system  for  the  Customer  Integrated  Auto¬ 
mated  Purchasing  System  (CIAPS),  which  operates  In  a  batch 
mode' on  the  shared  Phase  IV  SHOO  System.  BCAS  Is  currently 
being  Installed  and  Implemented  In  base  contracting  offices 
throughout  the  Air  Force.  As  BCAS  Is  Installed  and  Imple¬ 
mented  In  the  contracting  offices  on  a  particular  base, 

CIAPS  Is  removed  from  the  shared  SHOO  at  that  base's  data 
processing  center. 

The  BCAS  Program  Manager,  the  BCAS  System  Manager, 
and  the  CIAPS  ADS  Manager  are  the  same  person.  As  the 
Program  Manager,  he  Is  responsible  for  all  the  actions 
required  to  Install  the  BCAS  hardware  and  Implement  the 
standard  BCAS  software  at  base  contracting  facilities 
throughout  the  Air  Force.  As  the  System  Manager,  he  Is 
responsible  for  all  the  actions  required  to  support  and 
maintain  BCAS  during  Its  operational  life  on  the  Wang  hard¬ 
ware.  As  an  ADS  Manager,  he  Is  responsible  for  maintaining 
the  operational  CIAPS  software  on  the  Phase  IV  SHOO  system. 
He  wears  three  hats. 

Nearly  all  the  personnel  who  work  on  the  BCAS  are 
assigned  to  the  DCS  for  Acquisition.  They  not  only  perform 
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the  bulk  of  the  life-cycle  memagement  and  customer  support 
functions,  which  the  DCS  for  System  Support  normally 
provides  for  shared  systems,  but  they  also  perform  the 
entire  range  of  software  maintenance  functions,  which  the 
DCS  for  Maintenance  eind  Modification  normally  provides  for 
those  data  systems  that  are  operating  In  the  field.  The  DCS 
for  Systems  Support  serves  only  as  a  liaison  between  the 
BCAS  Program  Manager  (and  System  Manger)  and  the  Air  Force 
Computer  Acquisition  Center  (APCAC)  for  contract  related 
Issues.  Also,  the  DCS  for  Systems  Support  Is  the  focal 
point  between  the  Wang  contractor  and  the  BCAS  Program 
Manager/System  Manager  for  new  system  software  releases  and 
any  other  system  related  problems  which  the  contractor  must 
resolve.  (In  effect,  the  DCS  for  System  Support  only  acts 
as  the  AMMUS  contract  monitor. )  With  the  exception  of  the 
liaison  and  contract  monitor  functions,  all  the  BCAS  life¬ 
cycle  management,  or  system  management  functions,  are 
performed  by  dedicated  BCAS  personnel.  With  respect  to 
CIAPS,  the  BCAS  equivalent  on  the  SHOO,  the  DCS  for  Systems 
Support  does  provide  the  customer  support  functions  (Quality 
Assurance,  Field  Support,  Release  Control  and  Software 
Distribution)  that  they  nonnally  provide  for  base  level 

standard  systems  that  operate  on  the  shared  Phase  IV 
21 

system. 

The  above  basically  describes  how  program  manage¬ 
ment,  systems  management,  and  ADS  management  functions  are 
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centralized  for  BCAS.  The  bulk  of  the  llfe-cycle  management 
functions  are  done  by  a  single  group  of  functional  and  data 
automation  personnel  who  are  dedicated  to  the  BCAS  (and 
CIAPS)  systems.  There  Is  no  separation  of  acqulsltlon> 
development,  and  Implementation  functions  from  operational 
maintenance  and  system  support  functions  to  fit  the  current 
Standard  Systems  Center  organization  structure.  Responsi¬ 
bilities  for  the  various  life-cycle  management  functions 
have  not  passed  from  the  DCS  for  Acquisition  to  the  DCS  for 
Maintenance  and  Modification  (for  functional  software  main¬ 
tenance)  and  the  DCS  for  Systems  Support  (for  Configuration 
Management  of  hardware  and  software)  as  was  envisioned  when 
the  current  SSC  organization  structure  was  finalized. 

There  are  several  reasons  why  management  responsi¬ 
bilities  have  not  moved  through  the  SSC  as  It  Is  now 
organized.  First,  the  SSC  Is  still  maturing  with  respect  to 
the  current  "cradle  to  grave"  organizational  structure  that 
Is  Intended  to  support  a  system  throughout  Its  life.  For 
ez€unple,  more  trained  program  management  or  acquisition 
specialists  are  needed  to  support  the  acquisition  function. 
The  majority  of  the  Program  Managers  today  are  functional 
area  specialists,  e.g.,  medical,  logistics,  procurement 
specialists,  transportation,  communlcatlons-computer 
specialists,  etc.,  who  have  not  been  trained  as  program 
managers.  Second,  when  a  program  does  transfer,  the  SSC 
experience  to-date  has  mainly  been  that  no  resources 
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tr£uisferred  with  the  program.  This  la  unlike  a  typical  Air 
Force  Systems  Command  (APSC)  procurement,  where  selected 
manpower  authorizations  would  transfer  with  the  program  to 
APLC  or  emother  major  command  for  system  support. 

Another  significant  factor  Is  the  high  volume  of 
changes  which  occur  to  the  standard  base  level  systems. 
These  systems  don't  stabilize  like  embedded  software  In  a 
weapons  system.  They  are  always  being  revised,  either  as 
the  result  of  new  requirements,  or  changes  to  existing 
requirements,  or  due  to  statutory  changes.  This  constant 
state  of  change  makes  It  very  difficult  to  separate  acqui¬ 
sition  and  development  functions  (which  apply  basically  to 
new  requirements  or  major  revisions)  from  maintenance  and 
modification  functions  (which  is  fixing  system  errors  or 
Incorporating  minor  revisions.)  The  Instability  of  the 
functional  system  coupled  with  the  fact  that  "we  don't  PMRT 
standard  systems  outside  the  SSC"  (organization)  makes  It 
very  difficult  to  separate  program  management,  ADS  manage¬ 
ment,  and  system  management  activities . 

The  above  scenario  Is  not  limited  to  the  functional 
areas  of  "base  contracting."  There  are  a  number  of  other 
functional  areas  where  all  or  part  of  the  Program  Manage¬ 
ment,  ADS  Management,  and  System  Management  activities  are 
combined  and  performed  by  personnel  dedicated  to  a  parti¬ 
cular  standard  base  level  system.  Some  examples  are: 
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Functional  Area 

Hardware 

System  Title 

Engineers 

Wang 

Work  Information  Mgmt 

System 

Services  Information  Mgmt 
System 

Comptroller 

System  II 

System  2200  (Previously 
called  Comptroller  Office 
of  the  Future) 

Hospital 

Data  Point 

Medical  Material  Management 
System-On-Llne 

Are  the  functional  areas  satisfactorily  performing 
the  bulk  of  the  life-cycle  management  or  system  management 
functions  for  their  dedicated  systems?  If  BCAS  is  represen¬ 
tative  of  the  other  dedicated  fiinctlonal  system  users,  then 
it  appears  the  dedicated  systems  are  being  well  managed. 
"Doing  basically  all  the  management  actions  related  to 
implementing  EGAS  has  allowed  us  to  be  much  more  productive. 
We  have  been  able  to  respond  much  more  quickly  to  field 
concerns.  Contracting  offices  who  have  received  BCAS  much 
prefer  it  over  CIAPS  where  they  were  Just  another  user  of 
the  base  level  computer."  Being  able  to  direct  questions  or 
concerns  regarding  basically  any  area  of  the  system  to  a 
single  office  has  been  a  big  factor  In  Improving  "customer 
satisfaction"  with  the  base  contracting  community.  Since 
the  hardware  Is  dedicated  "we  don't  have  to  be  overly 
concerned  about  additional  workload  put  on  the  system,  or 
the  Impact  of  proposed  software  changes  on  overall  systems 
performance,"  as  Is  the  case  on  the  shared  system.  As  a 
result,  new  or  revised  functional  requirement  changes  can  be 
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"Implemented  much  more  quickly"  than  on  the  shared  system. 

The  Impact  assessment  and  evaluation  Is  done  almost 

completely  by  the  people  dedicated  to  BOAS.  If  technical 

assistance  Is  needed  It  Is  normally  provided  by  the 

personnel  assigned  to  the  "small  computer  office,"  who 

monitor  the  small  computer  requirements  contracts,  e.g., 

23 

AMMUS. 

The  small  computer  program  office,  which  Is  located 
within  the  DCS  for  System  Support  and  manages  the  small 
computer  requirements  contracts.  Is  "mainly  concerned  with 
monitoring  the  contract  and  acting  as  a  liaison  between  the 
dedicated  system  managers  and  the  Air  Force  Computer  Acqui¬ 
sition  Center,  and  the  contractors,  for  contract  related 
Issues.  We  don’t  centrally  control  the  hardware  and  soft¬ 
ware  for  the  small  computers  like  we  have  to  do  for  the  big 
box  system."  The  dedicated  system  managers  are  "responsible 
for  handling  Just  about  all  the  management  functions 
associated  with  fielding  their  systems  and  maintaining 
them."  The  program  office  monitors  contractor  compliance, 
monitors  the  status  of  equipment  delivery  orders  (via  on¬ 
line  access  to  the  contractor's  ordering  system),  evaluates 
and  tests  new  contractor  products,  processes  contract  modi¬ 
fications,  keeps  the  field  apprised  of  any  activities 
related  to  potential  contract  changes  for  new  hardware  or 
software  Items  that  may  be  added  to  the  contract(s),  and 
performs  other  similar  contract  related  functions.  The 
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progreun  office  also  works  closely  with  the  various  dedicated 

system  managers  to  identify,  and  add  to  the  contract,  any 

contractor  services  that  could  potentially  benefit  all  users 

of  the  requirements  contracts,  e.g.,  training,  software 
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support  services,  site  planning,  etc. 

Summary 

The  systems  management  (or  life-cycle  management) 
Infrastructure  used  to  manage  standard  base  level  communica¬ 
tions  computer  systems  has  clearly  changed.  Instead  of  a 
single  central  organization  charged  with  the  overall  system 
management  of  the  entire  base  level  automation  environment 
which  consists  mainly  of  a  single  shared  main  frame 
computer,-  we  now  have  system  management  responsibility  for 
base  level  systems  spread  across  many  different  functional 
areas.  This  process  has  evolved  as  the  result  of  functional 
areas  moving  their  automated  data  systems  off  the  central 
base  computer  to  Individual  dedicated  hardware  which,  in 
most  cases,  was  acquired  off  standard  Air  Force  small 
computer  requirements  contracts.  Instead  of  a  single  large 
main  frame  computer  being  used  for  base  level  support,  we 
have  a  mix  of  mlnls/mlcros  spread  across  the  base. 

The  System  Manager  responsible  for  life-cycle, 
management  of  the  Air  Force's  standard  large  main  frame 
computer  system  (Phase  IV)  faces  an  Impossible  task.  He  Is 
faced  with  performing  life-cycle  management  of  a  computer 
system  where  concurrently  there  are  major  acquisition 
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efforts  underway  off  the  same  contract.,  e.g.,  CAMS.  In 
this  situation.  It's  not  always  clear  who  the  responsible 
authority  Is,  the  system  manager  or  the  program  managers. 

The  system  manager  must  maintain  a  horizontal  relationship 
with  each  Program  Manager,  who  often  maintains  a  vertical 
relationship  with  the  air  staff  functional  managers.  Also, 
with  major  efforts  being  made  to  modernize  the  functional 
applications,  as  well  as  the  continuing  efforts  to  Incor¬ 
porate  functional  requirement  changes,  the  system  manager 
must  Interact  horizontally  with  ADS  managers  throughout  the 
software  development  process.  The  system  manager  must 
continually  try  to  assess  the  Impact  of  all  standard  system 
changes  on  the  performance  of  the  overall  system.  In 
addition  to  the  horizontal  relationship  with  the  Program 
Managers  and  the  ADS  Managers,  the  system  manager  needs  to 
be  aware  of  any  hardware  of  unique  applications  software  the 
major  commands  Implement  on  their  systems.  As  was  discussed 
In  Chapter  V,  this  horizontal  relationship  Is  characteristic 
of  systems  acquired  under  the  700  series  regulations.  Under 
the  700  series  regulations,  LCM  after  PMRT  Is  decentralized 
to  base  level  Instead  of  being  centralized  with  a  system 
manager  as  Is  the  case  In  APLC  under  the  800  series 
regulation. 

When  the  Phase  IV  contract  was  modified  to  allow  the 
commands  to  purchase  directly  off  the  contract,  centralized 
management  of  Phase  IV  computer  resources  was  basically 


lost.  "The  strength  of  the  centralized  ADPS  Management 
approach  for  the  Burroughs  systems  (pre-Phase  IV)  was  that 
we  always  knew  what  was  in  the  field  and  what  was  coming 
down  the  pike,"  In  terms  of  hardware  and  software  changes. 
"There  were  automated  tools  to  help  us  track  what  hardware 
and  software  was  at  the  bases,  such  as  the  Configuration 
Analysis  and  Projection  System."  Today,  we  don’t  have  a 
system  that  brings  configuration  management,  hardware 
ordering,  bill  paying,  and  software  and  hardware  Inventory 
fxinctlons  together.  This  Tiakes  It  nearly  Impossible  to 
determine  what  computer  resources  are  located  at  bases 
throughout  the  Air  Force  and  to  perform  certain  life  cycle 
management  fun-itlons  such  as  projecting  equipment  mainte¬ 
nance  costs.  "A  system  like  4PMS  Is  sorely  needed"  so  that 
life  cycle  management  functions  can  be  centralized  and 

managed  for  the  base  level  standard  communlcatlons-computer 
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systems,  be  they  large,  medium,  or  small.  IPMS  will  do  a 
lot  to  bring  together  a  number  of  the  life-cycle  management 
functions,  but  It  will  not  solve  the  problem  with  the  major 
commands  Implementing  unique  software  on  the  shared  system 
without  advising  the  systems  manager  of  the  added  workload. 
There  Is  no  real-time  solution  to  this  problem  other  than 
the  major  commands  complying  with  (the  regulation)  and 
allowing  the  Phase  IV  Systems  Manager  to  fully  assess  the 
Impact  of  any  major  command  unique  software  on  the  total 
system  before  It  is  Implemented. 
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Besides  the  challenges  facing  the  Phase  IV  system 
manager,  our  brief  look  at  how  system  management  Is  being 
applied  for  our  base  level  computer  systems  revealed  several 
other  areas  of  concern.  In  today’s  environment  we  see 
Individuals  performing  simultaneously  as  a  Program  Manager, 
ADS  Manager,  and  as  a  Systems  Manager.  We  see  a  niunber  of 
program  managers  for  some  major  programs  who  are  functional 
area  specialists  as  opposed  to  acquisition  management 
specialists  who  have  been  formally  trained  as  program 
managers.  We  see  program  management,  software  development, 
and  life-cycle  management  functions  being  done  by  personnel 
dedicated  to  a  single  functional  system,  yet  the  systems 
management  organization.  In  which  this  environment  exists, 
(l.e.,  the  Standard  Systems  Center)  Is  structured  basically 
to  emulate  the  APSC/APLC  environment  where  management 
responsibility  moves  to  separate  organizations  as  the  system 
moves  from  the  requirements  phase  to  the  operational  and 
malnten2uice  phase.  We  see  systems  PMRT  within  a  single 
organization  with  no  resources  normally  moving  with  the 
system  due  to  the  high  volume  of  change  associated  with  the 
systems,  and  the  difficulty  In  separating  acquisition  and 
development  functions  from  operation  and  maintenance 
functions. 

Does  this  type  of  environment  suggest  that  APCC 
should  not  be  the  Air  Force  System  Manager  for  the  standard 
base  level  communlcatlons-computer  systems?  Should  the 
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acquisition,  development  and  follow-on  life-cycle  management 
of  standard  base  level  communlcatlons-computer  systems  be 
turned  over  to  APSC  and  APLC?  Some  would  argue  that  this 
should  be  the  case,  but  there  are  a  couple  of  things  we  need 
to  keep  In  mind  when  discussing  whether  acquisition  and 
maintenance  of  standard  base  level  computer  systems  should 
be  done  by  AFSC  and  APLC.  Plrst,  there  Is  a  large  amount  of 
research  and  development  associated  with  weapon  system 
procurements.  This  Is  not  the  case  for  standard  base  level 
communlcatlons-computer  systems  where  associated  hardware 
and  system  software  are  commercially  acquired.  Secondly, 
once  embedded  support  software. Is  operational  for  weapon 
systems  (or  the  weapon  system  Is  In  production)  It  remains 
fairly  stable  with  little  follow-on  changes.  In  this 
environment.  It  Is  rather  easy  to  separate  maintenance  (fix 
or  repair)  efforts  from  new  development.  This  Is  not  the 
case  for  standard  base  level  systems  where  functional  appli¬ 
cations  have  shown  a  history  of  change,  either  modifying 
existing  requirements  or  adding  new  ones.  The  continuous 
opening  up  of  the  software  makes  It  difficult  to  separate 
operational  maintenance  activities  from  development 
activities. 

Plnally,  there  Is  one  additional  area  our  brief 
analysis  of  the  current  system  management  has  revealed. 
Regardless  of  the  series  regulations  used  to  field  a  system, 
there  Is  no  single  organization  looking  at  the  total  base 


level  environment  from  a  communlcations-computer  stand- 
point.  We  are  continuing  to  develop  base  level  systems  on 
both  the  shared  computer  and  the  dedicated  systems  in  a 
"stove  pipe"  fashion.  There  is  little  effort  underway  to 
integrate  data  bases  between  functional  systems  euid  to  allow 
them  to  "talk"  to  each  other.  Integration  of  data  bases  and 
communications  between  systems  has  to  come  for  base  level 
systems  1  It  is  essential  that  these  systems  be  developed  so 
they  can  communicate  with  each  other  and  are  hardware 
Independent.  Our  systems  must  be  developed  with  an  eye 
toward  the  future  where  multi-level  functional  data  is 
accessible  to  commanders  on  a  real-time  basis.  Our  base 
level  systems  must  be  made  to  be  interoperable. 
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CHAPTER  VII 


CONCLUSIONS  AND  RECOMMENDATIONS 

The  concerns  stated  In  this  paper  are  a  result  of 
the  Air  Force  policy  and  procedures  not  maturing  and  keeping 
pace  with  the  availability  of  funds  to  meet  the  Immediate 
backlog  of  communlcatlons-computer  system  requirements  for 
both  standard  and  unique  functional  systems.  The  lack  of 
updated  guidance,  coupled  with  the  need  to  satisfy  unique 
Information  processing  system  requirements  drove  the  Air 
Force  acquisition  decisions  which  by-passed  normal 
acquisition  discipline.  Because  procedures  did  not  stay 
abreast  with  actual  acquisitions,  life-cycle  management  and 
system  integration  suffered. 

The  following  recommendations  are  provided  as  a 
summation  of  this  paper: 

A.  While  there  Is  much  work  currently  being  done  to 
revise  the  700  series  regulations,  a  new  regulation 
combining  the  700  and  8oo  series  regulations,  as  they  apply 
to  acquisition  and  life-cycle  management  of  communlcatlons- 
computer  systems  Is  required.  This  new  regulation  should 
address  standardizing  procedures  and  terminology. 
Standardized  procedures  are  necessary  so  that  acquisition 
and  life-cycle  management  can  be  performed  without  using  two 
different  sets  of  procedures  depending  on  the  program 
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complexity,  or  requirement  of  the  Program  Management 
Document  (PMD). 

B.  Regardless  of  whether  Air  Force  System  Command 
or  Air  Force  Communication  Command  or  any  other  command 
acquires  a  system,  the  Program  Manager  must  have  the  total 
vertical  authority  for  his  program  and  be  given  the  funds  to 
provide  total  life-cycle  management  until  PMRT.  No  system 
should  be  acquired  unless  life-cycle  management  Is  fully 
funded  and  this  life-cycle  management  funding  Is  affixed  and 
transferred  to  the  supporting  command.  Furthermore,  life¬ 
cycle  management  should  not  be  decentralized.  The  visi¬ 
bility  of  all  standard  systems  (whether  functionally 
acquired  or  Integrated  as  part  of  the  Shared  system)  must  be 
centralized  either  with  Air  Force  Logistics  Command  or  a 
standard  Communlcatlons-Computer  Systems  Center  as  a  direct 
reporting  unit  of  HQ  USAF/SC. 

The  life-cycle  meinagment  organization  should  be 
responsible  for  overseeing  the  entire  standard  base  level 
communications  computer  systems  environment.  This  organi¬ 
zation  should  provide  centralized  LCM  and  should  have 
engineering,  acquisition,  and  management  overslte  for  all 
standard  systems  (large,  medium,  and  small)  which  operate  In 
the  base  level  environment.  The  centralized  manager  should 
be  responsible  for  Insuring  systems  being  acquired  or 
developed  are  being  done  In  a  manner  consistent  with  Air 
Force  Policy  regarding  the  use  of  standard  hardware 
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contracts,  software  development  standards,  use  of  portable 
operating  systems,  and  fourth  generation  programming 
languages,  etc.  This  organization  would  work  closely  with 
the  organization  responsible  for  the  AP  base  level  communl- 
catlons-*computer  system  architecture.  Acquisition  Program 
managers  and  support  system  managers,  regardless  of  system 
size,  must  be  directly  Involved  with  the  standard  systems 
manager  who  Is  responsible  for  the  current  large  "shared" 
system  (Phase  IV)  In  terms  of  configuration  management, 
system  performance,  workload  sizing,  evaluation  of  new 
contractor  proposed  hardware  and  software,  etc.  This 
organization  would  also  monitor  the  system  managers  on  the 
small  and  medium  dedicated  computer  systems  to  Insure 
compliance  with  established  systems  management  policy. 

C.  The  centralized  management  organization  should 
accelerate  the  activation  of  the  Implementation  Processing 
Management  System  (IPMS).  IPMS  Is  urgently  needed  now  to 
support  the  System  Manager  for  the  shared  SHOO,  however, 
this  system  should  be  considered  as  the  Air  Force  standard 
base  level  configuration  management  system  for  all  base 
level  computer  systems.  (See  Appendix  for  a  description  of 
IPMS. ) 

D.  A  restructuring  of  the  Air  Force’s  standard 
systems  acquisition  and  life-cycle  management  processes,  and 
organizational  alignments  Is  necessary  If  cost  effective 
acqulslton  and  life-cycle  management  Is  to  become  a  reality. 
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While  much  work  Is  ongoing.  If  the  basic  relationships  and 
structured  realignments  are  not  made,  effective  management 
of  communlcatlons-computer  systems  Is  as  questionable  In  the 
future  as  In  the  past. 


85 


M 


BIBLIOGRAPHY 


Acquisition  of  Computer  Resources.  Letter,  The  Under¬ 
secretary  of  Defense  for  Research  and  Engineering  to 
Secretaries  of  the  Military  Department,  4  March 

1983. 

Acquisition  Program  Management.  Air  Force  Regulation  800-2. 
Washington,  DC:  Department  of  the  Air  Force,  16 
September  1985. 

Air  Force  Computers,  Development  Risks  of  Logistics 

Modernization  Program  Can  be  Reduced.  Report  to  the 
Chairman,  Committee  on  Government  Operations,  House 
of  Representatives,  Washington,  DC:  General 
Accounting  Office,  May  1987. 

Air  Force  Seeks  Bids  for  Large  Multiuser  Contract. 

INI-OWGrlD.  23  March  1907. 

Amendment  of  Sollcltatlon/Modlflcatlon  of  Contract  F19630~ 
81-D-OOO2.  Amendment  Number  P0004b.  Standard 
Systems  Center,  Gunter  AFS,  Alabama,  1  September 

1985. 

Automated  Data  Processing  Resources  Management,  DOD 

lilrectlve  7956.1,  Washington,  Dc:  Department  of 
Defense,  29  September  I980. 

Base  Level  Implementation  of  Phase  IV.  Report  of  Audit. 

USAF  Audit  Agency,  Norton  Air  Force  Base, 

California,  22  August  I986. 

Combat  Support  Doctrine.  Air  Force  Manual  2-15. 

Washington,  DC:  Department  of  the  Air  Force,  13 
December  I985. 

Communications  Electronic  Roles  and  Missions  Study. 

AFCC/AFLC  Working  Group  (Air  Force  Logistics 
Command,  Deputy  Chief  of  Staff  Plans  and  Prograsm)* 

9  July  1987. 

Coy,  Peter.  "Pundits  Divided  Over  Whether  Computer  Industry 
Maturing."  Associated  Press  Montgomery  Advertiser, 
24  Jemuary  1988. 

DOD  Inforaatlon  Resources  Management  Program.  DOD  Directive 
7740.1,  Washington,  DC:  Department  of  Defense,  20 
Jvine  1983  • 


86 


DOD-Wlde  Guideline  for  Acquiring  Computer  Resources  Under  10 
U.S.C.  231^  (Armed  Services  Procurement  Act  -  Warner 
Amendment Public  Law  97~^6,  1  December  I9B1. 
Washington,  DC:  Department  of  Defense  Memorandum,  4 
March  1988. 

Federal  Property  and  Administrative  Services  Act,  1949* 

U.S.  Congress,  Title  I  (Public  Law  89-306,  89th 
Congress.  H.R.  4845,  36  October  I965. 

Goff,  Robert,  Major,  USAP.  HQS  Standard  Systems  Center, 

Gunter  AFS,  Alabama.  Interview,  22  January  1988. 

Heltkamp,  Kenneth  B.  Air  Force  Base-Level  Information 

Systems.  HQS  Air  University,  Maxwell  APB,  Alabama, 
April  1987 . 

Heltkamp,  Kenneth  B.  Modernization  of  Base  Level  Standard 

Computer  Systems,  HQS  Standard  Systems  Center,  Gunter 
APS,  Alabama,  Oepartment  of  the  Air  Force,  16  December 

1987. 

HQS  Standard  Systems  Center,  SSC  Pamphlet  ?3-l.  Gunter  APS. 

Alabama,  Department  of  the  Air  Force,  4  January  1980. 

HQS  Standard  Systems  Center  History.  Standard  Information 
Systems  Center  ileorganization  Notes,  24  October 

■  1986. 

Information  Systems  Program  Management  and  Acquisition.  Air 
Force  Regulation  YUO-4.  Washington,  DC:  Departmen t 
of  the  Air  Force,  15  March  I985. 

Integrated  Logistics  Support  (ILS)  Program.  Air  Force 

Regulation  800-8.  Washington,  DC:  Department  of  the 
Air  Force,  25  June  1986. 

Interim  Report  on  Air  Force  Base-Level  Automation  Environment. 

Washington,  DC:  N^lonal  Academy  of  Sciences.  January 

1986. 

Life  Cycle  Cost  Management  Program.  Air  Force  Regulation 
bOO-11.  Washington,  DC:  Department  of  the  Air 
Force,  27  Jeinuary  1984. 

Life  Cycle  Management  of  Automated  Information  Systems 
(ATS),  DOD  Directive  7920.1,17.  Washington,  DC: 
Department  of  Defense,  October  1978. 


87 


Logistics  Support  for  Ground  Conmunlcatlons-Electronlca 

(C-E)  Systems  and  Equipment.  Air  Force  Regulation 
00-26.  Washington,  DC:  Department  of  the  Air 
Force,  10  March  197 o. 

Management  of  Federal  Information  Resources.  Executive 

Office  of  the  J»resldent,  Washington,  DC:  Office  of 
Management  and  Budget,  Circular  No.  A-130,  12 
December  1985- 

Managing  Air  Force  Communlcatlons-Computer  Systems.  AFR  700-1, 
Washington,  DC:  Department  of  the  Air  Force,  15 
Jemuary  1987. 

Managing  Commxinlcatlons-Computer  Systems.  HQS  Standard 

Systems  Center.  SSCR  700-1.  Gunter  AFS,  Alabama: 
Department  of  the  Air  Force,  I8  December  1987 . 

McConeghy,  James,  Major,  USAF.  HQS  Standard  Systems  Center, 
Giinter  AFS,  Alabama.  Interview,  29  January  I988. 

Modernization  Plan  for  Standard  Air  Force  Information 
Systems  on  t^hase  IV  Base  Level  Computers.  HQS 
Standard  Systems  Center,  Gunter  AFS,  Alabama.  I6 
November  I988 . 

Organization  and  Mission  Field:  Air  Force  Commylcatlons 

Command"  A^’ft  ^5-32.  Washington,  DC:  Department  of 
the  Air  Force,  6  March  I980. 

Organization  and  Mission  Field:  HQ  Standard  Information 

Systems  Center  I  AiPCCR  23-2.  Scott  APB,  Illinois : 
Department  of  the  Air  Force,  15  July  1985. 

Operational  Needs.  Air  Force  Regulation  57-1.  Washington, 

DC:  Department  of  the  Air  Force,  28  May  1985 • 

Paper  Work  Reduction  Reauthorlzatlon.  U.S.  Congress,  Title 
VIII,  Senate  Bill  No.  S^i*36l,  12  October  1984 

(Public  Law  99-500,  Title  VIII,  Part  A). 

Phase  IV  Lessons  Learned  (Implementation  Period  Source 
Selection) .  Dunter  APs,  Alabcuna:  Air  Force 
Automated  Systems  Project  Office,  22  April  1983. 

Procedures  for  Managing  Automated  Data  Processing  Systems, 

ADPS  Management.  AFR  300-12,  Vol.  II,  Change  4, 
Washington,  DC:  Department  of  the  Air  Force,  15  June 

1982. 


88 


Wilkowske,  K.  V.,  Colonel,  USAF.  HQS  Standard  Systems  Center, 
Gunter  APS,  Alabama.  Interview,  3  February  1988. 


89 


APPENDIX 


DEFINITIONS 

The  definition  of  terms  and  systems  as  used  In  this 
paper  Is  necessary  as  some  slight  differences  exist  between 
Office  of  Management  and  Budget  (0MB),  DOD,  and  Air  Force 
definitions.  The  following  teras  contained  In  AFR  700-1, 
Attachment  1,  15  January  1987,  and  AFR  700-26  (Cl),  25 
November  1986  are  presented  for  reference:  18  December  1987, 
are  used  for  the  purpose  of  this  paper. 

CoBBand  CoBBunlcatlons-Coaputer  System.  Any  communlcatlons- 
computer  system  not  designed  as  a  standard  communlcatlons- 
computer  system.  These  systems  are  typically  managed  by  the 
command  In  which  they  operate. 

CoBmand  CoBBiinleatlons-Coaputer  Systems  Officer.  An  Indivi¬ 
dual,  designed  by  the  commander,  responsible  for  the  overall 
management  of  communlcatlons-computer  systems  budgeted  and 
funded  by  that  commeind. 

CoBBunlcatlons-Computer  System.  A  combination  of  equipment, 
procedures,  and  other  resources  used  to  process  Information. 
Processing  proceeds  from  creation  of  the  Information  by  the 
system  user  to  serial  or  concurrent  phases  of  protection, 
analysis,  storage,  retrieval,  and  dissemination  to  Intended 
recipients  for  disposition. 

Embedded  Systems.  Information  processing  components  speci¬ 
fically  designed  Into,  or  dedicated  to,  a  system  as  an 
Integral  part  of  the  overall  system,  capable  of  satisfying 
only  the  requirements  for  which  the  system  was  designed. 

Information.  Any  communications  or  reception  of  knowledge 
such  as  facts,  data,  or  opinions.  Including  numerical, 
graphic,  or  narrative  forms,  whether  oral  or  maintained  In 
any  medium.  Including  computerized  data  bases,  paper,  micro¬ 
form,  or  magnetic  tape  (Office  of  Management  and  Budget 
(0MB)  Circular  No.  1-130). 

Information  Resource  Management  (IRM).  The  planning, 
budgeting,  organizing,  directing,  training,  and  control 
associated  with  government  Information.  The  term  encom¬ 
passes  both  Information  Itself  and  the  related  sources,  such 
as  personnel,  equipment,  funds,  and  technology  (0MB  Circular 
No.  A-130). 


90 


standard  Conmunleatlons'-Coiiputer  Syatea.  An  Air  Force 
coBmunlcatlons-computer  system  that  affects  more  than  one 
MAJCOM  £Uid  requires  centralized  oversight  In  planning, 
design,  development,  system  Implementation,  operation,  or 
maintenance.  It  Is  normally  characterized  by  some  or  all  of 
the  following:  high  cost,  multiple  Interfaces,  multicommand 
users,  or  Air  Force-wide  system  objectives  and  Is  designated 
In  Table  2.2,  AFR  700-3. 

Standard  Connunlcatlons-Coiqputer  System  Manager.  The 
Individual  or  organization  designated  In  table  2-2,  AFR  700- 
3,  manage  a  standard  communlcatlons-computer  system. 

Small  Computer. 

a.  The  term  small  computer  Is  generic  and  refers  to 
a  specific  class  of  equipment  to  Include  associated  peri¬ 
pherals  and  software.  It  will  be  the  primary  end-user 
device  for  connection  to  networks  as  well  as  providing 
stand-alone  processing  capability.  It  has  the  capacity  to 
execute  various  software  programs  and  usually  consists  of  at 
least  a  keyboard,  disk  drive,  visual  display  device,  and 
central  processing  tinlt  with  random  access  and  read-only 
memory.  Commercial  personal  computers,  dedicated  text  pro¬ 
cessors  (memory  typewriters  and  related  equipment  previously 
known  as  word  processing  equipment).  Intelligent  work 
stations  used  for  translation  processing  on  a  multi-user 
computer.  Intelligent  typewriters  and  portable  computers  are 
all  examples  of  small  computers.  Some  multl-use  computers 
are  also  classed  as  small  computers. 

b.  Standard  small  computer  refers  to  computer 
resources  acquired  from  an  Air  Force-wide  requirements 
contract. 

Software.  Two  types  of  software  .operate  on  small  computers. 

a.  Operating  system  software  operates  the  computer 
hardware's  basic  system  functions  such  as:  providing  basic 
Input  and  output  routines,  file  maintenance  procedures,  and 
systems  controls. 

b.  Applications  software  accomplishes  the  user 
requirements.  It  cem  be  general-purpose,  commercial, 
vendor-supplied  software  (programs)  for  word  processing, 
data  base  management,  and  spread  sheets,  or  It  can  be  pro¬ 
grams  specifically  developed  by  users  for  unique  problems. 
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The  following  description  of  the  Implementation  of 
Processing  Management  System  (IPMS)  Is  provided  as  used  In 
Chapter  VI : 

Information  Processing  Management  System  (IPMS).  A  proposed 
automated  system  for  the  Sperry  1100  to  "manage  the  Infor¬ 
mation  processing  hardware,  software,  facilities,  personnel, 
and  budget  Information  for  all  Standard  Information 
Systems...”  The  major  fimctlonal  objective  of  IPMS  "Is  to 
provide  a  comprehensive  centralized  data  base  and  software 
system  to  effectively  track  the  ordering  of  all  hardware  and 
software,  the  Installation  of  that  hardware  and  software, 
the  payment  for  that  hardware  and  software  to  the  respective 
vendors,  the  training  of  the  Information  processing 
personnel  to  utilize  the  hardware  and  software,  the  faci¬ 
lities  to  house  the  hardware,  and  the  budget  Information  to 
support  all  facets  of  the  Information  processing  mission." 
IPMS  Is  being  prototyped  In  the  Standard  Systems  Center 
(SSC).  This  system  would  provide  users  (base,  division, 

SSC,  Hq  AFCC,  and  Hq  USAF/SC  on-line  access  via  the  Defense 
Data  Network  to  a  centralized  data  base  located  at  the  SSC. 
(Computer  System  Requirements  Document,  #86-0030  (SI), 
Information  Processing  Management  System  1100/60  Computer 
Support,  Staff  Summary  Sheet,  Hq  SSC/PRAII,  29  April  1987, 
Gunter  APS,  AL). 


•  » 

The  following  terms  are  taken  from  APR  57-1, 
Operational  Needs,  dated  28  May  19&5  (Attachment  2)  and  are 
presented  for  reference: 

Air  Force  Designated  Acquisition  Program  (AFDAP).  A  program 
that  Is  less  than  a  major  program  and  Milestone  I,  II,  and 
III  decisions  are  made  by  the  Secretary  of  the  Air  Force 
(SAP),  with  the  advice  of  the  Air  Force  Systems  Acquisition 
Review  Council.  APDAPs  will  usually  have  estimated  costs 
(Fiscal  Year  8o  dollars)  for  research,  development,  test, 
and  evaluation  (RDT&E)  between  $100  and  $200  million  or 
between  $500  million  and  $1  billion  for  procurement 
(production).  (Source:  APR  800-2.) 

Implementing  Command.  The  command  or  agency  that  a  Program 
Management  Director  (PMD)  designates  responsible  for  the 
program  objectives  or  program  phase  objectives  the  PMD 
establishes.  (Reference:  APR  800-2.) 

Integrated  Logistics  Support  (ILS).  A  disciplined,  unified, 
and  Iterative  approach  to  the  management  and  technical 
activities  necessary  to: 
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a.  Integrate  support  considerations  Into  system  emd 
equipment  design. 

b.  Develop  support  requirements  that  are  related 
consistently  to  readiness  objectives,  to  design,  and  to  each 
other. 


c.  Acquire  the  required  support. 

d.  Provide  the  required  support  during  the  opera¬ 
tional  phase  at  minimum  cost.  (Source:  DOD  Directive 

5000.30.). 

Justification  for  Major  System  New  Start  (JMSMS).  The  JMSMS 
Is  used  to  document  major  deficiencies  (or  opportunities  for 
Improvements)  In  operational  capabilities  when  It  Is  planned 
to  correct  such  deficiencies  (or  to  capitalize  on  such 
opportunities)  by  the  acquisition  of  a  major  new  system  or  a 
major  modification  to  an  existing  system.  A  JMSMS  must  be 
submitted  for  Office  of  Secretary  of  Defense  (OSD)  review 
not  later  than,  or  as  a  part  of  a  service's  Program 
Objective  Memorandum  (POM)  submission  In  which  funds  for  the 
budget  year  of  the  POM  are  requested  for  a  major  system  new 
start.  (Reference:  DOD  Directive  5000.1  and  DOD  Instruction 
5000.2.) 

Maj  or  Modification.  Any  system  modification  having 
estimated  cost  exceeding  $200  million  (PY  80  dollars)  In 
research,  development,  test  and  engineering  (RDT4E)  funds  or 
$1  billion  (FY  80  dollars)  in  procurement  funds  (or  both). 
(Reference:  DOD  Directive  5000.1.) 

Major  System.  Any  system  having  estimated  costs  exceeding 
$200  million  (FY  dollars)  In  research,  development,  test, 
and  engineering  (RDTiE)  funds  or  $1  billion  (PY  80  dollars) 
In  procurement  funds  (or  both)  or  as  directed  by  the  Office 
of  Secretary  of  Defense  (OSD)  Acquisition  Executive,  the 
Under  Secretary  of  Defense,  Research,  and  Engineering 
(USDR&E).  The  Acquisition  Executive  may  designate  systems 
having  lower  estimated  costs  as  major  systems  for  other 
reasons  such  as  development  risk,  urgency  of  need,  or  signi¬ 
ficant  Congressional  Interest).  (Reference:  DOD  Directive 
5000.1.) 

Originating  Command.  The  major  command  or  Separate 
Operating  Agency  that  originates  a  Statement  of  Operational 
Need  (SON). 

Participating  Command.  Program  Management  Directive  (PMD) 
designated  command  or  agency  that  provides  support  and  takes 
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part  In  carrying  out  tasks  the  PMD  and  Program  Management 
Plan  assign.  (Reference:  APR  800*-2.) 


The  following  terms  from  APR  700-3,  Information 
System  Requirements  Processing,  dated  1  October  I987  are 
presented  for  reference: 

Automation  Equipment  (AE).  General  and  special  purpose 
automatic  data  processing  equipment  (ADPE),  office  auto¬ 
mation  equipment.  Including  word  processors,  and  other 
communlcatlons-computer  processing  devices. 

CoBoninlcatlons-Computer  Systems  Requirements  Board  (CSRB).  ' 
The  board  established  under  APR  700-5  at  base  level,  MAJCOM, 
HQ  USAP,  and  If  required,  at  Intermediate  level  to  validate 
requirements  and  approve  technical  solutions  for 
communlcatlons-computer  systems  requirements. 

Coanninlcatlons-Computer  Systems  Requirements  Document 
(CSRD).  The  document  which  Identifies,  describes,  and 
justifies  the  need  for  communlcatlons-computer  systems  faci¬ 
lities,  equipment,  or  services.  It  also  Identifies  the 
Initial  technical  solution,  associated  resources,  and  costs 
for  fulfilling  the  need.  The  CSRD  replaces  previous 
requirements  documents,  such  as  Information  System  Require¬ 
ments  Document,  AP  Porm  1070,  Local  Communication  Service 
Request:  AP  Porm  1225,  BCTDS  Statement  of  Requirement:  Data 
Automation  Requirement  (DAR):  mlnl-DAR;  Programmed  Auto¬ 
mation  Requirement  (PAR);  and  Projected  Communications 
Requirement  (PCR). 

Communlcatlons-computer  Systems  Officer  (CSO).  At  base 
level,  the  commander  of  the  communlcatlons-computer  systems 
unit  responsible  for  carrying  out  the  communlcatlons- 
computer  systems  staff  officer  responsibilities.  At  MAJCOM 
level,  the  person  designated  by  the  MAJCOM  commander  who  Is 
responsible  for  overall  management  of  those  communlcatlons- 
computer  systems  budgeted  and  funded  by  the  MAJCOM. 

Implementing  Command.  The  coimnand  responsible  for  exer¬ 
cising  overall  management  of  an  approved  program  for  engi¬ 
neering,  Installing,  and  testing  the  facilities  or  equipment 
necessary  to  fulfill  a  requirement. 

MAJCOM  Functional  Counterpart.  The  organization  of  higher 
headquarters  to  which  the  activity  that  will  be  using  the 
required  capability  or  service  functionally  reports.  For 
example,  the  base  security  police  unit  counterpart  Is  the 
MAJCOM  SP. 
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Prograa  Managenent  DlreetiTa  (PHD).  The  official  HQ  USAF 
nanagement  directive  used  to  provide  direction  to  the  Imple¬ 
menting  and  participating  commands  and  satisfy  the  documen¬ 
tation  requirements.  It  will  be  used  during  the  entire 
acquisition  cycle  to  state  requirements  and  request  studies, 
as  well  as  to  Initiate,  approve,  change,  transition,  modify, 
or  terminate  programs.  The  content  of  the  PMD,  Including 
required  HQ  USAF  review  and  approval  actions.  Is  tailored  to 
the  needs  of  Individual  programs  (AFR  11-1). 

Standard  Coonunleatlons-Computer  Systems  Manager  (SCSM).  A 
person  or  organization  within  the  Air  Force  to  whom  HQ 
USAF/SC  has  assigned  responsibilities  and  delegated 
authority  to  carry  out  certain  duties  of  HQ  USAF/SC.  The 
SCSM  was  formerly  called  the  C-E  single  manager  In  the  C-E 
field  and  Standard  Automatic  Data  Processing  System  Manager 
under  ADPE. 


The  following  APR  700-4,  Information  System  Program 
Management  and  Acquisition  (15  March  I985)  terms  are 
presented  for  reference: 

Automated  Information  System  (AIS).  A  collection  of 
functional  user  and  Information  systems  personnel,  proce¬ 
dures,  and  equipment  which  is  designed,  built,  operated,  and 
maintained  to  collect,  record,  process,  store,  retrieve,  and 
display  Infoirmatlon. 

Automatic  Data  Processing  Equipment  (ADPE).  General- 
purpose,  commercially  available  automatic  data  processing 
equipment  and  the  systems  created  by  them. 

Automated  Data  System  (ADS).  An  assembly  of  procedures, 
processes,  methods,  routines,  or  techniques  (Including,  but 
not  limited  to  computer  programs)  united  by  regulated  Inter¬ 
action  to  form  an  organized  whole  and  specifically  designed 
to  make  use  of  ADPE. 

Information  System  Acquisition  Program.  A  directed  effort 
for  the  development  and  procurement  of  systems,  subsystems, 
equipment,  or  software,  as  well  as  supporting  equipment, 
systems,  or  projects,  which  Is  managed  under  the  APR  700- 
serles  regulations  with  the  goal  of  providing  a  new  or 
Improved  capability  for  a  validated  mission  need. 

Information  Systems  Directive  (ISD).  A  document  developed 
and  approved  by  the  Implementing  command  that  Identifies  key 
decisions,  assigns  responsibilities,  and  authorizes  specific 
resources  and  actions  to  develop  and  Implement  an  Infor¬ 
mation  system. 
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lofoniatlon  Systcu  Engineer.  The  Individual  responsible 
for  conducting  studies  to  determine  the  best  way  to  satisfy 
a  requirement  and  by  selecting  the  best  approach  for  Inte¬ 
grating  the  design  requirements  Into  a  total  system 
configuration. 

Information  Systems  Program  Plan  (ISPP).  The  central  plan 
which  controls  the  program  management  effort. 

Information  Systems  Requirement  Document  (ISRD).  The 
document  which  Identifies  and  describes  the  need  for  Infor¬ 
mation  systems  facilities,  equipment,  and  services.  It  also 
Identifies  the  Initial  technical  solution,  associated 
resources,  and  costs  for  fulfilling  the  need. 

Logistics  Assessment.  An  assessment  conducted  during 
program  management  to  determine  equipment  and  logistics 
support  availability  and  to  detez*mlne  actions  needed  to 
ensure  full  logistics  support  at  program  completion. 

Lowest  Total  Overall  Cost  (LTOC).  The  lowest  total  cost  to 
the  Government  for  a  system  over  Its  full  life  cycle.  It 
Includes  the  cost  of  development,  procurement,  operation, 
support,  and  disposal. 

Program.  For  the  purpose  of  this  regulation,  program  Is 
defined  as  a  formally  documented  plan  to  acquire  new,  addi¬ 
tional,  or  expanded  Information  systems  resources  or  to 
remove  specified  resources  In  order  to  satisfy  a  require¬ 
ment. 

Program  Action  Officer  (PAO).  An  Individual  assigned  to  a 
program  In  response  to  the  ISPP  to  coordinate  all  program- 
related  actions  assigned  to  their  activity  and  to  give 
status  Information  to  the  program  maneiger. 

Program  Manager.  The  single  Individual  In  the  Implementing 
command  with  the  full  authority  emd  responsibility  for 
managing  a  program.  There  Is  only  one  program  manager  for  a 
given  program;  however,  a  program  manager  may  manage  more 
than  one  program. 

Program  Management.  Coordinated  actions  that  result  In  the 
application  of  resources  to  fulfill  a  stated  need  and  the 
organized  effort  to  provide  equipment  and  software  to  meet  a 
stated  requirement. 

Program  Management  Directive  (PMD).  The  official  HQ  USAP 
management  directive  used  to  provide  direction  to  Imple¬ 
menting,  operating,  supporting,  and  participating  commands 
and  to  satisfy  documentation  requirements,  request  studies. 


and  Initiate,  approve,  change,  transition,  modify,  or 
terminate  programs.  The  content  of  the  PMD,  including 
required  HQ  USAP  review  and  approval  actions.  Is  tailored  to 
the  needs  of  each  program. 

Requiring  Command.  The  MAJCOM  that  needs  an  Information 
system,  service,  or  capability  to  accomplish  Its  mission. 


The  following  APR  800-2,  Acquisition  Program 
Management  (16  September  1985)  terms  are  presented  for 
reference : 


a.  Acquisition  Program.  A  directed  effort  funded 
either  through  procurement  appropriations;  through  the 
security  assistance  program;  or  through  the  research, 
development,  test  and  evaluation  appropriation,  with  the 
goal  of  providing  a  new  or  improved  capability  for  a  vali¬ 
dated  need.  An  acquisition  progreun  may  Include  either  the 
development  or  procurement  of  systems,  subsystems,  equip¬ 
ment,  munitions,  or  modifications  to  them,  as  well  as 
supporting  equipment,  systems,  projects,  and  studies. 
Excluded  from  this  definition  and  from  this  regulation  are 
the  general  purpose,  commercially  available  automatic  data 
processing  assets  defined  In  Air  Force  TOO-series  regu¬ 
lations. 


b.  Air  Force  Designated  Acquisition  Program 
(APDAP).  A  program  that  does  not  meet  the  dollar  thres-hold 
of  a  major  program  but  Milestone  I,  II,  and  III  decisions 
need  to  be  made  by  the  Secretary  of  the  Air  Force  (SAP), 
with  the  advice  of  the  Air  Force  Systems  Acquisition  Review 
Council.  APDAPs  usually  have  estimated  costs  (Fiscal  Year 
1980  dollars)  for  research,  development,  and  test  and 
evaluation  between  $100  and  $200  million,  or  $500  million 
and  $1  billion  for  procurement  (production). 

Implementing  Command.  The  command  or  agency  designated  by 
Headquarters,  United  States  Air  Force  to  manage  an  acqui¬ 
sition  program. 

Justification  for  Major  System  New  Start  (JMSMS).  The 
document  prepared  by  Headquarters,  United  States  Air  Force 
to  support  the  Initiation  of  a  major  acquisition  program  or 
Air  Force  Designated  Acquisition  Program  and  submitted  with 
the  Program  Objective  Memorandum  (POM)  In  which  funds  for 
the  budget  year  of  the  POM  are  requested. 

P®**^iclpatlng  Command.  A  command  or  agency  designated  by 
Headquarters,  United  States  Air  Force  to  support  and  advise 
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the  program  manager  (PM).  The  supporting  command  Is  also  a 
participating  command. 


Program  Management  Directive  (PMD).  The  official  Head¬ 
quarters,  United  States  Air  Force  management  directive  used 
to  provide  direction  to  Implementing  and  participating 
commands  and  to  satisfy  documentation  requirements.  It  Is 
used  during  the  entire  acquisition  cycle  to  state  require¬ 
ments,  request  studies,  and  Initiate,  approve,  change, 
transition,  modify,  or  tennlnate  programs.  The  content  of 
the  program  management  directive.  Including  required  Head¬ 
quarters,  United  States  Air  Force  review  and  approval 
actions.  Is  tailored  to  the  needs  of  each  Individual 
program. 

Program  Manager  (PH).  The  single  Air  Force  manager  (system 
program  director,  program  or  project  manager,  or  system  or 
Item  manager)  during  any  specific  phase  of  the  acquisition 
life  cycle. 

Supporting  Command.  The  command  assigned  responsibility  for 
providing  logistics  support;  It  assumes  program  management 
responsibility  from  the  Implementing  command. 

System  Program  Office  (SPO).  The  organization  comprised  of 
technical  and  business  management  and  administrative 
personnel  assigned  full-time  to  a  system  program  director. 
The  office  may  be  augmented  with  additional  personnel  from 
participating  organizations. 


The  following  APR  800-8,  Integrated  Logistics 
Support  (ILS)  Program  (25  June  1986)  terms  are  presented  for 
reference: 

Acquisition  Program.  An  acquisition  program  Is  a  directed 
effort  fxinded  either  through  procurement  appropriations; 
through  the  security  assistance  program;  or  through  the 
research,  development,  test  and  evaluation  (RDT&E)  appro¬ 
priation,  with  the  goal  of  providing  a  new  or  Improved 
capability  for  a  validated  need.  An  acquisition  program  may 
Include  either  the  development  or  procurement  of  systems, 
subsystems,  equipment,  munitions,  or  modifications  to  them, 
as  well  as  supporting  equipment,  systems,  projects,  and 
studies. 

Deputy  Program  Manager  for  Logistics  (DPNL).  The  DPML  Is  an 
experienced  logistician  assigned  to  a  major  program  office 
to  assist  In  executing  ILS  responsibilities  throughout  the 
acquisition  program. 
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Integrated  Logistics  Support  (ILS).  ILS  Is  a  disciplined, 
unified,  and  Iterative  approach  to  the  management  and  tech¬ 
nical  activities  necessary  to:  (a)  Integrate  support 
considerations  Into  system  and  equipment  design;  (b)  develop 
support  requirements  that  are  related  consistently  to 
readiness  objectives,  to  design,  and  to  each  other;  (c) 
acquire  the  required  support;  (d)  provide  the  required 
support  during  the  operational  phase  at  a  minimum  cost. 

Integrated  Logistics  Support  (ILS)  Elements.  The  ILS 
elements  are  the  principal  logistics  elements  that  must  be 
properly  Integrated  to  achieve  economical  and  effective 
support  of  a  system  or  equipment  throughout  Its  lifecycle. 
The  elements  of  ILS  are  defined  and  discussed  In  attachment 
3. 


Integrated  Logistics  Support  Manager  (ILSM).  The  ILSM  Is  an 
experienced  logistician  assigned  to  a  program,  not  desig¬ 
nated  as  a  major  program,  to  assist  In  executing  ILS  respon¬ 
sibility  throughout  the  acquisition  progrsun. 

Integrated  Logistics  Support  Office  (ILSO).  An  ILSO  Is  the 
ILS  office  within  a  program  office. 

Integrated  Logistics  Support  Plan  (ILSP).  The  ILSP  Is  an 
Air  Force  management  plan  developed  and  used  to  manage  the 
ILS  process.  This  Includes  the  horizontal  Integration  of 
the  ILS  elements  (that  Is,  with  each  other),  as  well  as 
their  vertical  Integration  Into  the  various  aspects  of 
program  planning,  engineering,  designing,  testing, 
evaluating,  and  during  production  and  operation.  It  also 
Includes  the  Integration  of  support  elements  with  the 
mission  elements  of  a  system  throughout  Its  lifecycle.  The 
ILSP  Is  Section  9,  Logistics,  of  the  program  management  plan 
(PMP)  and,  when  approved,  becomes  directive  on  all  parti¬ 
cipating  agencies.  Transition  of  the  ILSP  is  accomplished 
at  program  management  responsibility  transfer  (PMRT)  to 
ensure  effective  logistics  management  and  support  of  the 
system  during  post  production  as  a  part  of  the  program 
management  planning  effort.  This  planning  effort  Is 
continuously  updated  as  the  program  evolves. 

Integrated  Support  Plan  (ISP).  The  ISP  Is  an  Iterative 
document  prepared  and  updated  by  a  contractor  for  acceptance 
and  approval  of  the  acquiring  activity.  It  describes  the 
contractor’s  plan  for  managing  the  contractual  ILS  program, 
for  complying  with  the  specific  contractual  ILS  require¬ 
ments,  and  for  planning  any  operational  support  functions 
assigned  to  the  contractor. 
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Prograa  NanagMent  Plan  (PNP).  The  PMP  is  a  document 
developed  and  Issued  by  the  program  manager  that  shows  the 
integrated  time-phased  tasks  and  resources  required  to 
complete  the  task  specified  in  the  program  management 
directive  (PMD).  The  PMP  is  tailored  to  the  needs  of  each 
individual  program.  Section  9  (Logistics)  of  the  PMP  is 
developed  and  maintained  in  current  status  as  the  ILSP. 

Program  Manager  (PM).  The  PM  is  the  single  Air  Force 
manager  designated  by  the  implementing  command  to  manage  an 
acquisition  program. 


The  following  SSCR  700-1,  Managing  jCommunlcatlons- 
Computer  Systems,  Attachment  2,  l8  December  1987  terms  are 
presented  for  reference: 

Application  Software.  (Ftmctlonal)  consists  of  those 
routines  and  programs  designed  by  or  for  automatic  data 
processing  equipment  users  to  accomplish  specific,  mission- 
oriented  tasks,  Jobs,  or  functions  using  the  automatic  data 
processing  equipment  and  basic  software  available.  Appli¬ 
cation  software  may  be  either  general  purpose  packages,  such 
as  demand-deposit  accounting,  payroll,  machine  tool  control, 
etc.,  or  specific  application  programs  tailored  to 
accomplish  a  single  or  limited  number  of  users  functions, 
such  as  base  level  personnel,  depot  maintenance,  missile  or 
satellite  tracking,  etc.  Except  for  general  purpose 
packages  which  are  acquired  directly  from  software  vendors 
or  from  the  original  equipment  manufacturers,  this  type  of 
software  is  normally  developed  by  the  user,  either  with  in- 
house  resources  of  through  contract  services. 

Approval.  Approval  indicates  that  the  requirement  has  been 
validated  and  the  approving  agency  has  the  authority  to 
commit  resources  needed  to  acquire/produce  the  desired 
product.  Approval  also  indicates  that  the  requirement  is 
technically  and  economically  feasible  and  that  resources  are 
available  and  will  be  committed  to  the  program. 

Automated  Data  System  (ADS). 

a.  An  assembly  of  procedures,  processes,  methods, 
routines,  or  techniques  (including,  but  not  limited  to, 
computer  programs)  united  by  regulated  Interaction  to  form 
an  organized  whole  and  specifically  designed  to  make  use  of 
Automatic  Data  Processing  Equipment  (ADPE). 

b.  Subdivision/Identification  of  an  SCS  due  to  the 
degree  of  management  during  PPBS  activities. 
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Autrauted  Data  Syateaa  Kaintenaaea.  Efforts  associated  with 
the  elimination  of  faults  In  software  to  ensure  than  an  ADS 
Is  In  satisfactory  working  condition.  Fixing  faults  Is 
limited  to  DIREPs,  other  similar  trouble  reports ,  and 
Internally  discovered  program  and  documentation  errors  In 
operational  systems. 

Automated  Data  System  (ADS)  Manager.  An  Individual  who  Is 
responsible  for  Internal  planning,  organizing,  coordinating 
controlling,  and  directing  modification  and  maintenance  of 
software  system  (basic  or  application). 

Basle  Software.  (Non-function)  comprises  those  routines  and 
programs  designed  to  extend  or  facilitate  the  use  of  parti¬ 
cular  automatic  data  processing  equipment,  the  requirement 
for  which  takes  Into  account  the  design  characteristics  of 
such  equipment.  This  software  Is  usually  provided  by  the 
original  equipment  manufacturer  and  Is  normally  essential 
to,  and  a  part  of,  the  system  configuration  furnished  by  the 
manufacturer.  Examples  of  basic  software  are  executive  and 
operating  programs;  diagnostic  programs;  compilers; 
assemblers;  utility  routines,  such  as  sort-merge  and  Input- 
output  conversion  routines;  file  management  programs;  and 
data  management  programs.  Data  management  programs  are 
commonly  linked  to,  and/or  under  the  control  of,  the  execu¬ 
tive  or  operating  programs. 

Command  Unique  Communleations-Computer  Systems.  A 
eommiuilcatlons-computer  system  which  supports  a  function 
performed  at  one  MAJCOM. 

Communleations-Computer  System.  A  combination  of  equipment, 
procedures,  and  other  resources  used  to  process  Information. 
Processing  proceeds  from  creation  of  Infor-matlon  by  the 
system  user  to  serial  or  concurrent  phases  of  protection, 
analyses,  storage,  retrieval,  and  dissemination  to  Intended 
recipient  for  disposition. 

Dedicated  System  Manager.  The  dedicated  system  manager  Is 
the  person  responsible  for  managing  systems  which  are  con¬ 
sidered  to  be  subsets  of  a  Standard  Communication-Computer 
System  In  the  context  used  by  HQ  USAP  (SCS-59*  10,  8o,  ^9, 
etc.)  and  usually  consist  of  dedicated  hardware  In  support 
of  one  functional  area  or  one  ADS.  The  responsibilities  of 
the  dedicated  system  manager  are  a  subset  of  those  of  the 
system  manager. 

Management  Documents.  Management  documents  are  those  which 
provide  overall  program  definition,  visibility,  and  decision 
making  capability.  Examples  of  these  documents  are  the 
CSRD,  SDN,  CSD,  CSPP,  MENS,  SON,  cost/economlc  analysis. 
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feasibility  study,  Prellmlneury  Technical  Survey  Report 
(PTSR),  and  Energy  Requirements  Plan  (ERP). 

Program  Manager.  An  individual  with  authority  and  respon¬ 
sibility  for  the  acquisition  and/or  development  of  new 
requirements  for  major  communlcatlons-computer  systems. 
Program  management  requires  special  management  skills  and 
supporting  management  structures  to  ensure  the  effective  and 
efficient  completion  of  tasks  and  responsibilities  as 
defined  In  the  program's  associated  management  documents. 

Requirements  Manager.  The  individual  or  activity  that 
serves  as  the  focal  point  for  all  S3C  communlcatlons- 
computer  systems  tasks  received  from  both  Internal  and 
external  sources  that  require  acquisition/production  work 
and  monitoring  through  the  IRR.  This  function  Is  assigned 
to  HQ  SSC/PR. 

Requirements  Processing.  The  process  of  documenting, 
analyzing,  and  approving  requirements  so  that  resources  can 
be  obtained  and  allocated  to  acquire/produce  the  solution 
that  will  best  satisfy  the  requirement  In  minimum  time. 

Standard  Communlcatlons-Coaqputer  System  (SCS).  A 
communlcatlons-computer  system  which  affects  more  than  one 
major  command  and  requires  centralized  overslte  In  planning, 
design,  development,  acquisition.  Installation,  operation, 
or  maintenance. 

Standard  Communleatlon-ConDuter  Systems  Manager  (SCSC).  A 
person  or  organization  within  the  Air  Force  to  whom  HQ 
USAF/SC  has  assigned  responsibilities  and  delegated  the 
authority  to  meuiage  standard  communlcatlons-computer 
systems.  The  SCSC  was  formerly  called  the  Communlcatlons- 
Electronlc  (C-E)  Single  Manager  In  the  C-E  field  and 
standard  Automatic  Data  Processing  Systems  (ADPS)  manager 
under  ADP,  SSC/CC  Is  the  SCSM  for  all  standard 
communlcatlons-computer  systems  assigned  to  the  SSC. 

Standard  Systems  Center  Unique.  A  communlcatlons-computer 
system  that  supports  a  function  at  SSC. 

System.  A  composite  of  equipment,  skills,  and  techniques 
capable  of  performing  and/or  supporting  an  operational  role. 
A  complete  system  Includes  related  facilities,  equipment, 
materiel,  services,  and  personnel  required  for  Its  operation 
to  the  degree  that  It  can  be  considered  a  self-sufficient 
unit  In  Its  Intended  operational  and/or  support  environment. 

System  Manager.  The  system  manager  Is  responsible  for 
controlling  all  technical  aspects,  both  hardware  and 
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software,  for  communlcatlons-cooputer  systems  assigned  to 
SSC  from  PMRT  until  system  cancellation. 

Validation.  Validation  indicates  that  the  stated  need  or 
requested  service  is  a  true  need.  Validation  does  not 
necessarily  lead  to  the  expenditure  of  resources.  To  be 
valid,  requirements  must  provide  needed  Improvement  In 
mission  capability,  comply  with  Air  Force  doctrine. 

Implement  Air  Force  plans,  and  meet  the  guidelines  set  down 
In  communlcatlons-computer  systems  directives  such  as  the 
Air  Force  700-  series  regulations.  Validation  by  the  CSRB 
should  lead  to  the  expenditure  of  funds  or  commitment  of 
other  resources  if  the  requirement  is  later  funded  through 
the  Programming,  Planning  and  Budgeting  System  process. 
Validated  requirements  must  be  approved  before  resources  may 
be  expended  on  the  requirement. 
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